存在的问题
- 执行大表的全表查询(select *)进程被kill;
- 创建GIST、GIN等索引进程被kill;
原因:
- Linux 内核根据应用程序的要求分配内存,绝大部分应用程序不会同时使用全部内存,为了提高性能,内核采用(over-commit memory)内存分配办法来间接利用这部分 “空闲” 的内存,提高整体内存的使用效率。
- 当大多数应用程序都消耗完分配的内存时,所有应用已分配的内存超出了物理内存时(包括 swap),内核(OOM killer)会kill一些进程保障系统正常运行。OOM killer通过计算oom score选取进程进行删除。
解决方法
- 增加物理内存或调整SWAP交换空间;
- 调整work_mem、max_connections参数;
- 使用更严格的内存提交策略overcommit_memory:
- 通过oom_adj干预oom killer;
调整work_mem、max_connections参数
按照官方文档建议: work_mem * max_connections <= RAM + SWAP
加载
- 测试数据:2G
- 并发数: 11~99
- 测试环境:RAM 32G,swap 32G
- pg数据库配置:
max_connections=100
shared_buffers=8G
work_mem=320M
maintenance\_work_mem=64M - 测试结果:并发达到连接上限(100),

本文探讨了在Postgres服务中遇到的并发问题,包括全表查询和索引创建过程中进程被kill的情况。文章分析了Linux内核的内存过量承诺策略和OOM Killer机制,并介绍了调整work_mem、max_connections参数以及overcommit_memory的方法来优化并发性能。测试结果显示,适当调整参数可以在并发执行大表查询和创建索引时避免内存异常。然而,由于psql进程的内存占用,当并发数过高时仍可能出现问题。文章提出进一步的测试计划,包括增加数据量和测试服务端进程。

1670

被折叠的 条评论
为什么被折叠?



