尽管有足够的可用内存，但Postgres会出现内存错误
Posted
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了尽管有足够的可用内存，但Postgres会出现内存错误相关的知识，希望对你有一定的参考价值。
我有一台运行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获取确切的数字，与此同时这是我所有信息的题材。
关于从哪里去的任何想法？
当错误加剧时，你能检查是否有可用的交换内存？
我完全删除了我的Linux桌面中的交换内存（仅用于测试其他内容......），我得到了完全相同的错误！我很确定这也是你发生的事情。
我刚刚尝试使用~2.5 GB纯文本SQL文件遇到了同样的问题。我将我的数字海洋服务器扩展到64 GB RAM，创建了一个10 GB的交换文件，并再次尝试。我得到了一个内存不足的错误，50 GB可用，没有交换使用。
我将我的服务器缩减到我正在使用的小1 GB实例（需要重新启动），并认为我会给它另一个镜头，除了我感到沮丧之外别无他法。我开始导入并意识到我忘了再次创建临时交换文件。
我在导入过程中创建了它。在崩溃之前，psql使它更进一步。它通过5个额外的表格。
我认为必须在psql中分配内存的bug。
您报告与shared_buffers大小相同的可用内存大小有点可疑。你确定你看到了正确的价值观吗？
在崩溃时输出free命令以及/ proc / meminfo的内容是有用的
请注意，如果将overcommit_memory设置为100，则将overcommit_ratio设置为2并不是那么有效。它将基本上限制内存分配到大小交换（在这种情况下为0）+ 100％物理RAM，这不考虑任何共享内存和磁盘缓存的空间。
您应该将overcommit_ratio设置为50。
以上是关于尽管有足够的可用内存，但Postgres会出现内存错误的主要内容，如果未能解决你的问题，请参考以下文章