使用可能なメモリ（キャッシュ）にもかかわらずOOM

メモリのほぼ半分がFSキャッシュに使用されているにもかかわらず、OOMキラーに遭遇しました。メモリ統計は毎分1回記録されています（トップが報告）が、十分な可用性があるようです。

...

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

...

syslogからの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
...

これらの解像度を1秒に1回程度に上げることもできますが、ここにOOMの理由はありますか？（http://bl0rg.krunch.be/oom-frag.htmlを見てきましたが、はるかに大きい絶対メモリ量で作業しており、そのほとんどはカーネルのFSキャッシュによって使用されます。）

postgresql.conf以下の関連部分も含む：

shared_buffers = 6GB
effective_cache_size = 8GB

postgresql oom

— ヤン
ソース

関連チャットディスカッション

— ヤン

あの... 3.2.0-43？更新時間。OOMキラーは、時間の経過とともに多くの（多すぎる）変更を経験してきました。PostgreSQL 9.2以前のように、一部のバージョンは、共有メモリの使用を考慮することに関して非常に頭がおかしかったshared_buffersです。

— クレイグリンガー

@CraigRinger残念ながら、LTS、互換性、セキュリティ更新など、Ubuntu 12.04ディストリビューションのカーネルに固執するなど、他の考慮事項があります。現状を変えたり、問題を解決したりすることに興味がない。BTW shared_buffersはまだPG9.3にあります。

— ヤン

はいshared_buffersはまだ9.3にありますが、9.3 ではPOSIX共有メモリではなくなりました。匿名mmap()ed地域に置き換えられました。これにより、いくつかの厄介なカーネル構成の問題と固定の問題が回避されますが、OOMのキラーが混乱することはないでしょう。

— クレイグリンガー

おそらく重複serverfault.com/questions/288319/...潜在的な答えを持っています、。

— -richvdh

回答:

あなた（そして私が非常によく似た症状の場合）は本当にメモリ不足になり、そのcached数に混乱しているようです。

メモリの需要が上がったときにLinuxが大きなディスクキャッシュを解放しない場合があるようです

特に（実際には理由はわかりません）、postgres ' shared_buffersは "Cached"（ページキャッシュ）で報告されます。あなたの場合、6481852k cachedin topはOOM-killerのログのこの行と一致します：

Jun 10 05:45:25 db kernel: [11209156.840788] 1615243 total pagecache pages

（1615243 * 4KB〜= 6481852k）-OOM-killerを呼び出す前にページキャッシュが実際に削除されなかったことを意味します。

それでも、ファイルに裏付けられたページはほとんどありません（active_file:98 inactive_file:168/ proc / meminfoのActive（file）/ Inactive（file）に類似していると思われます）。

https://www.depesz.com/2012/06/09/how-much-ram-is-postgresql-using/の投稿は、postgresをシャットダウンすると「キャッシュされた」サイズがshared_buffers（「それは共有キャッシュに使用されていたため、予想どおり、ほとんどがディスクキャッシュから外れました。」）-残念ながら、実験に使用されたpostgresのバージョンもカーネルも示していません。

PG 9.3で3.13.0-67 x86_64を使用しています。9.3では、Sys V共有メモリの使用（shmget）から匿名mmap(...R+W, MAP_SHARED|MAP_ANONYMOUS|MAP_HASSEMAPHORE...)+fork()に切り替えました（9.4では、これはdynamic_shared_memory_typeで構成可能になりました）。しかし、これらのmmap（）が「キャッシュ」に表示されるはずである理由と、「キャッシュ：メモリ内のメモリ」というhttps://access.redhat.com/solutions/406773のみについての説明は見つかりませんでしたページキャッシュ（ディスクキャッシュと共有メモリ）」

多くの種類の共有メモリがあることを考えると、私は啓発されて混乱しています...

— ニコロイ
ソース

数年後、これははるかに良い答えです、ありがとう。なぜこれがキャッシュされていると見なされるのかという疑問はありますが、今のところこれを受け入れているとマークしています。

— ヤン

世界で良いものすべてを愛するために、サーバーのスワップスペースを構成します。
本当にスワップスペースが必要です。そう言うのは私だけではない、それはこの辺りのほぼ普遍的な真実だ。（<-これらは3つのリンクです）
もちろん、データベースサーバーが定期的にスワップしないように十分なRAMを用意する必要があります-ソリューションがお金でない場合（ベンダーに連れて行って、より多くのRAMを取得するために使用します）。
十分なRAMがあり、何か問題が発生した場合に使用するスワップがあるので、Postgresの人々が言うように、 OOMキラーを無効にできます（メモリのオーバーコミットを無効にすることで）。
（代替ソリューションを適用し、OOM-KillerにPostgresを絶対に殺さないように指示することもできます-ただし、システムの残りのプロセスでロシアンルーレットをプレイしているだけです...）
（オプション）ほとんどのLinuxディストリビューションのデフォルトの動作が悪い、間違っている、およびmalloc（）の動作方法に関するPOSIX仕様に違反している理由を詳述したサーバーフォールトの回答を記述します。誰もがそれについて聞いてうんざりするまでそれを繰り返します。

また、カーネルのキャッシュメモリはpostgres（またはその他のアプリケーション）が使用できることに注意してください-計算で空き/使用可能メモリとして考慮する必要があります。

ここで何が起こっているのかを推測しなければならない場合、複雑なクエリがあると思いますが、PostgresはRAMにそれを実行するように要求します。きみにあげる。"
そして、Postgresが実際にしようとしたときに使用だったRAMは、（容疑者）Linuxはそれがありません実現与えHAVE（それがオーバーコミットているため）、それはPostgresのを約束したRAMを- OOMキラーは、RAMを解放するように指示され、かつ忠実に使用してプログラムを殺しますほとんどのメモリ-データベースサーバー。

Postgresは適切に設計されたプログラムです。RAMを搭載できないと言われた場合は、それを適切に処理します（lessで対処するか、ユーザーへのメッセージで中止します）。

— voretaq7
ソース

スワップの詳細に感謝しますが、これはなぜこれが最初に起こっているのかという私の質問には答えません。はい、Linuxはデフォルトでオーバーコミットし、OOMはRAMが不足しているという基本的な前提を理解しています-私は元の質問でこれを述べたかもしれません。しかし、問題は、まだ十分なRAMがあるのになぜ起動するのかということです（その多くはFSキャッシュに残っているだけです）。何も変更することに興味がないと仮定します。OOMキラーは、トリガーされる理由を理解している限り、問題ありません。

— ヤン

リンクを確認した後、残念なことに、裏付けとなる証拠や具体的な技術的説明のない多くの主張があります。確かに、スワップが選択肢にならない多くのLinux環境があります（例：再利用する既存のローカルスワップパーティションがまだないLive CDを探す必要はありません）。さらに、私たちは私たち自身の経験と環境に基づいてスワップを可能にすることに興味がありません。元の質問への回答をいただければ幸いです。

— ヤン

@Yang私は、Postgres用のサーバーを構築している場合、Postgresプロジェクトの推奨事項に従うことを想定しています。私の答えは、彼らがあなたに言うことをすることです（OOMキラーを止めてください）。誰かがあなたに別の答えを提供するのを待って見たいなら、あなたは間違いなくそうすることができますが、私は他の解決策を提供するのは不安です-私の意見では、OOMキラーは悪い、間違っており、POSIXに違反しています。デスクトップ/ワーステーションでは許容されるかもしれませんが、サーバーで無効にすることは、IMO、The Right Thing To Doです。

— -voretaq7

スワップのあるサーバーでこの状況に遭遇しました。使用可能なメモリとスワップを飽和状態にした後、カーネルが「キャッシュ」メモリを回収する代わりにOOMキラーが使用されました。私は問題を解決しませんでしたが、@ Yangの元の質問はここでは答えられません。

— パトリック14年

スワップは答えではなく、問題が後で現れるだけです。RAMがいっぱいになるとスワップが必要になり、RAM + swapがいっぱいになるとOOM Killerが必要になります。スワップの量がゼロの場合、OOM Killerを早めに必要としますが、スワップでOOM Killerを回避することはできません。

— ミッコランタライネン