尽pipe将近一半的内存用于FScaching，但我们仍然遇到了OOM杀手。 我们已经每分钟logging一次内存统计信息（按顶部报告），但似乎有很多的可用性。
... Mem: 15339640k total, 15268304k used, 71336k free, 3152k buffers Swap: 0k total, 0k used, 0k free, 6608384k cached Mem: 15339640k total, 14855280k used, 484360k free, 13748k buffers Swap: 0k total, 0k used, 0k free, 6481852k cached [OOM killer: postgres killed] Mem: 15339640k total, 8212200k used, 7127440k free, 32776k buffers Swap: 0k total, 0k used, 0k free, 2394444k cached ... 系统日志中的OOM详细信息：
... Jun 10 05:45:25 db kernel: [11209156.840462] wal-e invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0, oom_score_adj=0 Jun 10 05:45:25 db kernel: [11209156.840469] wal-e cpuset=/ mems_allowed=0 Jun 10 05:45:25 db kernel: [11209156.840474] Pid: 7963, comm: wal-e Not tainted 3.2.0-43-virtual #68-Ubuntu Jun 10 05:45:25 db kernel: [11209156.840477] Call Trace: Jun 10 05:45:25 db kernel: [11209156.840498] [<ffffffff81119711>] dump_header+0x91/0xe0 Jun 10 05:45:25 db kernel: [11209156.840502] [<ffffffff81119a95>] oom_kill_process+0x85/0xb0 Jun 10 05:45:25 db kernel: [11209156.840506] [<ffffffff81119e3a>] out_of_memory+0xfa/0x220 Jun 10 05:45:25 db kernel: [11209156.840511] [<ffffffff8111f823>] __alloc_pages_nodemask+0x8c3/0x8e0 Jun 10 05:45:25 db kernel: [11209156.840520] [<ffffffff81216e00>] ? noalloc_get_block_write+0x30/0x30 Jun 10 05:45:25 db kernel: [11209156.840528] [<ffffffff811566c6>] alloc_pages_current+0xb6/0x120 Jun 10 05:45:25 db kernel: [11209156.840534] [<ffffffff81116637>] __page_cache_alloc+0xb7/0xd0 Jun 10 05:45:25 db kernel: [11209156.840539] [<ffffffff81118602>] filemap_fault+0x212/0x3c0 Jun 10 05:45:25 db kernel: [11209156.840553] [<ffffffff81138c32>] __do_fault+0x72/0x550 Jun 10 05:45:25 db kernel: [11209156.840557] [<ffffffff8113c2ea>] handle_pte_fault+0xfa/0x200 Jun 10 05:45:25 db kernel: [11209156.840562] [<ffffffff8100638e>] ? xen_pmd_val+0xe/0x10 Jun 10 05:45:25 db kernel: [11209156.840567] [<ffffffff81005309>] ? __raw_callee_save_xen_pmd_val+0x11/0x1e Jun 10 05:45:25 db kernel: [11209156.840571] [<ffffffff8113d559>] handle_mm_fault+0x269/0x370 Jun 10 05:45:25 db kernel: [11209156.840576] [<ffffffff8100a56d>] ? xen_force_evtchn_callback+0xd/0x10 Jun 10 05:45:25 db kernel: [11209156.840581] [<ffffffff8100ad42>] ? check_events+0x12/0x20 Jun 10 05:45:25 db kernel: [11209156.840589] [<ffffffff8165b3cb>] do_page_fault+0x14b/0x520 Jun 10 05:45:25 db kernel: [11209156.840594] [<ffffffff81160d64>] ? kmem_cache_free+0x104/0x110 Jun 10 05:45:25 db kernel: [11209156.840600] [<ffffffff811ba2c8>] ? ep_remove+0xa8/0xc0 Jun 10 05:45:25 db kernel: [11209156.840604] [<ffffffff811bb133>] ? sys_epoll_ctl+0xb3/0x3d0 Jun 10 05:45:25 db kernel: [11209156.840614] [<ffffffff81658035>] page_fault+0x25/0x30 Jun 10 05:45:25 db kernel: [11209156.840617] Mem-Info: Jun 10 05:45:25 db kernel: [11209156.840618] Node 0 DMA per-cpu: Jun 10 05:45:25 db kernel: [11209156.840622] CPU 0: hi: 0, btch: 1 usd: 0 Jun 10 05:45:25 db kernel: [11209156.840624] CPU 1: hi: 0, btch: 1 usd: 0 Jun 10 05:45:25 db kernel: [11209156.840627] CPU 2: hi: 0, btch: 1 usd: 0 Jun 10 05:45:25 db kernel: [11209156.840629] CPU 3: hi: 0, btch: 1 usd: 0 Jun 10 05:45:25 db kernel: [11209156.840631] Node 0 DMA32 per-cpu: Jun 10 05:45:25 db kernel: [11209156.840634] CPU 0: hi: 186, btch: 31 usd: 30 Jun 10 05:45:25 db kernel: [11209156.840637] CPU 1: hi: 186, btch: 31 usd: 47 Jun 10 05:45:25 db kernel: [11209156.840639] CPU 2: hi: 186, btch: 31 usd: 15 Jun 10 05:45:25 db kernel: [11209156.840641] CPU 3: hi: 186, btch: 31 usd: 2 Jun 10 05:45:25 db kernel: [11209156.840643] Node 0 Normal per-cpu: Jun 10 05:45:25 db kernel: [11209156.840646] CPU 0: hi: 186, btch: 31 usd: 0 Jun 10 05:45:25 db kernel: [11209156.840648] CPU 1: hi: 186, btch: 31 usd: 14 Jun 10 05:45:25 db kernel: [11209156.840650] CPU 2: hi: 186, btch: 31 usd: 0 Jun 10 05:45:25 db kernel: [11209156.840653] CPU 3: hi: 186, btch: 31 usd: 1 Jun 10 05:45:25 db kernel: [11209156.840658] active_anon:3616567 inactive_anon:4798 isolated_anon:0 Jun 10 05:45:25 db kernel: [11209156.840660] active_file:98 inactive_file:168 isolated_file:20 Jun 10 05:45:25 db kernel: [11209156.840661] unevictable:1597 dirty:73 writeback:0 unstable:0 Jun 10 05:45:25 db kernel: [11209156.840662] free:16921 slab_reclaimable:17631 slab_unreclaimable:7534 Jun 10 05:45:25 db kernel: [11209156.840663] mapped:1614529 shmem:1613928 pagetables:124012 bounce:0 Jun 10 05:45:25 db kernel: [11209156.840666] Node 0 DMA free:7888kB min:4kB low:4kB high:4kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:7632kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes Jun 10 05:45:25 db kernel: [11209156.840681] lowmem_reserve[]: 0 4016 15112 15112 Jun 10 05:45:25 db kernel: [11209156.840686] Node 0 DMA32 free:48368kB min:4176kB low:5220kB high:6264kB active_anon:3776804kB inactive_anon:28kB active_file:0kB inactive_file:20kB unevictable:932kB isolated(anon):0kB isolated(file):0kB present:4112640kB mlocked:932kB dirty:0kB writeback:0kB mapped:1458536kB shmem:1458632kB slab_reclaimable:17604kB slab_unreclaimable:8088kB kernel_stack:1872kB pagetables:190616kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:437 all_unreclaimable? yes Jun 10 05:45:25 db kernel: [11209156.840698] lowmem_reserve[]: 0 0 11095 11095 Jun 10 05:45:25 db kernel: [11209156.840703] Node 0 Normal free:11428kB min:11548kB low:14432kB high:17320kB active_anon:10689464kB inactive_anon:19164kB active_file:528kB inactive_file:652kB unevictable:5456kB isolated(anon):0kB isolated(file):80kB present:11362176kB mlocked:5456kB dirty:292kB writeback:0kB mapped:4999580kB shmem:4997080kB slab_reclaimable:52920kB slab_unreclaimable:22048kB kernel_stack:2584kB pagetables:305432kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:1974 all_unreclaimable? yes Jun 10 05:45:25 db kernel: [11209156.840715] lowmem_reserve[]: 0 0 0 0 Jun 10 05:45:25 db kernel: [11209156.840720] Node 0 DMA: 2*4kB 3*8kB 1*16kB 3*32kB 3*64kB 3*128kB 2*256kB 1*512kB 2*1024kB 2*2048kB 0*4096kB = 7888kB Jun 10 05:45:25 db kernel: [11209156.840752] Node 0 DMA32: 5813*4kB 2636*8kB 114*16kB 15*32kB 5*64kB 1*128kB 1*256kB 0*512kB 1*1024kB 0*2048kB 0*4096kB = 48372kB Jun 10 05:45:25 db kernel: [11209156.840776] Node 0 Normal: 1888*4kB 10*8kB 46*16kB 4*32kB 3*64kB 2*128kB 1*256kB 1*512kB 0*1024kB 1*2048kB 0*4096kB = 11760kB Jun 10 05:45:25 db kernel: [11209156.840788] 1615243 total pagecache pages Jun 10 05:45:25 db kernel: [11209156.840790] 0 pages in swap cache Jun 10 05:45:25 db kernel: [11209156.840801] Swap cache stats: add 0, delete 0, find 0/0 Jun 10 05:45:25 db kernel: [11209156.840803] Free swap = 0kB Jun 10 05:45:25 db kernel: [11209156.840805] Total swap = 0kB Jun 10 05:45:25 db kernel: [11209156.909794] 3934192 pages RAM Jun 10 05:45:25 db kernel: [11209156.909804] 99282 pages reserved Jun 10 05:45:25 db kernel: [11209156.909809] 18899146 pages shared Jun 10 05:45:25 db kernel: [11209156.909811] 2198511 pages non-shared Jun 10 05:45:25 db kernel: [11209156.909817] [ pid ] uid tgid total_vm rss cpu oom_adj oom_score_adj name Jun 10 05:45:25 db kernel: [11209156.909835] [ 332] 0 332 4308 109 1 0 0 upstart-udev-br Jun 10 05:45:25 db kernel: [11209156.909845] [ 346] 0 346 5384 271 2 -17 -1000 udevd Jun 10 05:45:25 db kernel: [11209156.909851] [ 408] 0 408 5364 174 2 -17 -1000 udevd ... Jun 10 05:45:25 db kernel: [11209156.910703] [ 7963] 111 7963 17456 2966 0 0 0 wal-e Jun 10 05:45:25 db kernel: [11209156.910707] [ 7968] 111 7968 1639372 2351 3 0 0 postgres Jun 10 05:45:25 db kernel: [11209156.910711] [ 7969] 111 7969 1639371 1934 2 0 0 postgres Jun 10 05:45:25 db kernel: [11209156.910716] Out of memory: Kill process 12443 (postgres) score 418 or sacrifice child Jun 10 05:45:25 db kernel: [11209156.910733] Killed process 12443 (postgres) total-vm:6555152kB, anon-rss:4600kB, file-rss:6396572kB Jun 10 05:45:30 db kernel: [11209159.293083] postgres invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0, oom_score_adj=0 Jun 10 05:45:31 db kernel: [11209159.293091] postgres cpuset=/ mems_allowed=0 Jun 10 05:45:31 db kernel: [11209159.293095] Pid: 6508, comm: postgres Not tainted 3.2.0-43-virtual #68-Ubuntu Jun 10 05:45:31 db kernel: [11209159.293098] Call Trace: Jun 10 05:45:31 db kernel: [11209159.293111] [<ffffffff81119711>] dump_header+0x91/0xe0 Jun 10 05:45:31 db kernel: [11209159.293115] [<ffffffff81119a95>] oom_kill_process+0x85/0xb0 Jun 10 05:45:31 db kernel: [11209159.293119] [<ffffffff81119e3a>] out_of_memory+0xfa/0x220 ...
我们可以尝试将这些解决scheme的速度提高到每秒大概一次，但是在这里有没有任何一个OOM的理由？ （我们已经看到http://bl0rg.krunch.be/oom-frag.html，但是我们正在处理更大的绝对内存量，其中大部分内存都是由内核的FScaching占用的）。
还包括下面的postgresql.conf相关部分：
shared_buffers = 6GB effective_cache_size = 8GB
看来你（和我在一个非常相似症状的情况下）已经真的用完了记忆，并且被cached号码弄糊涂了。
在内存需求上升的情况下， Linux显然有些情况下没有释放大容量磁盘caching
特别是（我不明白为什么）， postgres的shared_buffers可能会在“Cached”（页面caching）下被报告。 在你的情况下， 6481852k cached在top匹配OOM杀手的日志中的这一行：
Jun 10 05:45:25 db kernel: [11209156.840788] 1615243 total pagecache pages
（1615243 * 4KB〜= 6481852k） – 表示在调用OOM杀手之前，页面caching确实没有被丢弃。
然而，很less有文件支持页面（我认为active_file:98 inactive_file:168类似于/ proc / meminfo的Active（文件）/ Inactive（文件） ），所以它不是我们所知道和喜欢的可丢弃页面。
在https://www.depesz.com/2012/06/09/how-much-ram-is-postgresql-using/的post演示了一个closurespostgres的示例会话，导致“caching”减less了大小shared_buffers （滚动到“其中大部分来自磁盘caching – 正如所料，因为它被用于shared_buffers。” ） – 不幸的是，它并不表示postgres的版本和实验中使用的内核。
我在PG 9.3上使用3.13.0-67 x86_64。 在9.3中，他们从使用SysV共享内存（ shmget ）切换到匿名mmap(...R+W, MAP_SHARED|MAP_ANONYMOUS|MAP_HASSEMAPHORE...)+fork() （在9.4中，这可以通过dynamic_shared_memory_type进行configuration）。 但我找不到任何解释，为什么这些mmap（）应该显示在“caching”，为什么，只有https://access.redhat.com/solutions/406773说：“caching：内存中的页面caching（Diskcache和共享内存）“
考虑到共享内存的种类很多，我既开悟又困惑。
为了爱世界上的一切，请在服务器上configuration交换空间 。
你真的需要交换空间 。 我不是唯一一个这样说的人 ， 这里几乎是一个普遍的真理 。 （< – 这是三个链接）
你当然应该拥有足够的内存来保证你的数据库服务器不会经常交换 – 如果你不解决问题，那么你的解决scheme就是金钱（你把你的供应商用来获得更多的内存）。
既然你现在有足够的内存，并且在出现问题时使用swap，那么你可以像Postgres人告诉你的那样禁用OOM杀手（通过禁用内存过量使用）。
（你也可以申请他们的替代解决scheme，并告诉OOM杀手永远不会杀死Postgres – 但是，你只是玩俄罗斯轮盘与你的系统的其他过程…）
（可选） 在Server Fault上写一个答案，详细说明为什么大多数Linux发行版中的默认行为是错误的，错误的，违反了POSIX规范的malloc（）应该如何performance 。 重复它，直到每个人都厌倦了听到它。
还要注意，内核的caching内存可用于postgres（或任何其他应用程序）使用 – 你应该把它作为计算中的空闲/可用内存。
如果我不得不冒险猜测这里发生了什么，我会说你有一个复杂的查询，Postgres正在请求RAM来执行它，而不是说“我没有那个RAM”Linux告诉Postgres“当然，你可以拥有它。”
然后，当Postgres实际上试图使用内存时（据说）给了Linux意识到它没有它承诺的Postgres的RAM（因为它被过度使用） – OOM杀手被告知释放内存，并忠实地杀死程序最多的内存 – 你的数据库服务器。
Postgres是一个精心devise的程序。 如果它被告知不能拥有内存，它会请求它正常处理（或者通过less做或者用消息中止用户）。