Question

我有一台运行Postgres 9.1.15的服务器。服务器有2GB的RAM，没有交换。 Postgres会间歇性地开始在某些SELECT上出现“内存不足”错误，并且会继续这样做，直到我重新启动Postgres 或某些连接到它的客户端。有什么奇怪的是，当发生这种情况时，free仍会报告超过500MB的可用内存。

select version();：

PostgreSQL 9.1.15 on x86_64-unknown-linux-gnu, compiled by gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3, 64-bit

uname -a：

Linux db 3.2.0-23-virtual #36-Ubuntu SMP Tue Apr 10 22:29:03 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

Postgresql.conf（其他所有内容都被注释掉/默认）：

max_connections = 100
shared_buffers = 500MB
work_mem = 2000kB
maintenance_work_mem = 128MB
wal_buffers = 16MB
checkpoint_segments = 32
checkpoint_completion_target = 0.9
random_page_cost = 2.0
effective_cache_size = 1000MB
default_statistics_target = 100
log_temp_files = 0

我从pgtune获得了这些值（我选择了“混合类型的应用程序”），并根据我所阅读的内容摆弄它们，但没有取得太多实际进展。目前有68个连接，这是一个典型的数字（我还没有使用pgbouncer或任何其他连接的连接器）。

/etc/sysctl.conf：

kernel.shmmax=1050451968
kernel.shmall=256458

vm.overcommit_ratio=100
vm.overcommit_memory=2

在OOM杀手杀死Postgres服务器后大约两周前，我首先将overcommit_memory更改为2。在此之前，服务器已经运行了很长时间。我现在得到的错误不是灾难性的，而是更加烦人，因为它们更频繁。

我没有太多的运气指出导致postgres“内存不足”的第一个事件 - 每次似乎都不同。它崩溃的最近一次，记录的前三行是：

2015-04-07 05:32:39 UTC ERROR:  out of memory
2015-04-07 05:32:39 UTC DETAIL:  Failed on request of size 125.
2015-04-07 05:32:39 UTC CONTEXT:  automatic analyze of table "xxx.public.delayed_jobs"
TopMemoryContext: 68688 total in 10 blocks; 4560 free (4 chunks); 64128 used
[... snipped heaps of lines which I can provide if they are useful ...]

---

2015-04-07 05:33:58 UTC ERROR:  out of memory
2015-04-07 05:33:58 UTC DETAIL:  Failed on request of size 16.
2015-04-07 05:33:58 UTC STATEMENT:  SELECT oid, typname, typelem, typdelim, typinput FROM pg_type
2015-04-07 05:33:59 UTC LOG:  could not fork new process for connection: Cannot allocate memory
2015-04-07 05:33:59 UTC LOG:  could not fork new process for connection: Cannot allocate memory
2015-04-07 05:33:59 UTC LOG:  could not fork new process for connection: Cannot allocate memory
TopMemoryContext: 396368 total in 50 blocks; 10160 free (28 chunks); 386208 used
[... snipped heaps of lines which I can provide if they are useful ...]

---

2015-04-07 05:33:59 UTC ERROR:  out of memory
2015-04-07 05:33:59 UTC DETAIL:  Failed on request of size 1840.
2015-04-07 05:33:59 UTC STATEMENT:  SELECT... [nested select with 4 joins, 19 ands, and 2 order bys]
TopMemoryContext: 388176 total in 49 blocks; 17264 free (55 chunks); 370912 used

之前的崩溃，几个小时前，刚刚将最后一个查询的三个实例作为崩溃的前三行。该查询经常运行非常，所以我不确定问题是因为这个查询，还是它只是出现在错误日志中，因为它是合理的复杂的SELECT一直在运行。也就是说，这是一个解析分析：http://explain.depesz.com/s/r00

这是postgres用户的ulimit -a：

core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 15956
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 15956
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

下次发生崩溃时，我会尝试从free获取确切的数字，与此同时，这是我所有信息的标题。

关于从哪里去的任何想法？

Answer 1

我刚刚尝试使用~2.5 GB纯文本SQL文件遇到了同样的问题。我将我的数字海洋服务器扩展到64 GB RAM，创建了一个10 GB的交换文件，并再次尝试。我得到了一个内存不足的错误，50 GB可用，没有交换使用。

我将我的服务器缩减到我正在使用的小1 GB实例（需要重新启动），并认为我没有其他理由再给它一次，而不是让我感到沮丧。我开始导入并意识到我忘了再次创建临时交换文件。

我是在导入过程中创建的。在崩溃之前，psql使它成为 lot 。它通过了5个额外的表格。

我认为必须在psql中分配内存。

Answer 2

当错误加剧时，你可以检查是否有可用的交换内存？

我完全删除了Linux桌面中的交换内存（仅用于测试其他内容......），我得到了完全相同的错误！我很确定这也是你发生的事情。

Answer 3

您报告与shared_buffers大小相同的可用内存大小有点可疑。你确定你看到了正确的价值观吗？

崩溃时输出free命令以及/ proc / meminfo

的内容是有用的

请注意，如果您将overcommit_memory设置为100，那么将overcommit_ratio设置为2就不会那么有效。它基本上会将内存分配限制为大小交换（在这种情况下为0）+ 100％物理RAM，它没有考虑共享内存和磁盘缓存的任何空间。

您应该将overcommit_ratio设置为50。

尽管有足够的可用内存，但Postgres会出现内存错误

3 个答案: