Linux OOMキラーにプロセスを終了させないようにする方法は？

Question

物理メモリが少ないがスワップスペースが十分にある場合に、Linux OOMキラーにプロセスを強制終了させないようにするにはどうすればよいですか？

OOM killを無効にし、sysctl vm.overcommit_memory = 2でオーバーコミットしました。

VMには3 GBの完全に空きの断片化されていないスワップがあり、OOM killされているプロセスの最大メモリ使用量は200MB未満です。

長期的なスワッピングはパフォーマンスにとってひどいものになることはわかっていますが、メモリ要件がはるかに大きいvalgrindで機能テストを実行するには、今すぐスワップを使用する必要があります。

Mar 7 02:43:11 myhost kernel: memcheck-AMD64- invoked oom-killer: gfp_mask=0x24002c2, order=0, oom_score_adj=0 Mar 7 02:43:11 myhost kernel: memcheck-AMD64- cpuset=/ mems_allowed=0 Mar 7 02:43:11 myhost kernel: CPU: 0 PID: 3841 Comm: memcheck-AMD64- Not tainted 4.4.0-x86_64-linode63 #2 Mar 7 02:43:11 myhost kernel: Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014 Mar 7 02:43:11 myhost kernel: 0000000000000000 0000000000000000 ffffffff8158cbcc ffff880032d7bc18 Mar 7 02:43:11 myhost kernel: ffffffff811c6a55 00000015118e701d ffffffff81044a8d 00000000000003e2 Mar 7 02:43:11 myhost kernel: ffffffff8110f5a1 0000000000000000 00000000000003e2 ffffffff81cf15cc Mar 7 02:43:11 myhost kernel: Call Trace: Mar 7 02:43:11 myhost kernel: [<ffffffff8158cbcc>] ? dump_stack+0x40/0x50 Mar 7 02:43:11 myhost kernel: [<ffffffff811c6a55>] ? dump_header+0x59/0x1dd Mar 7 02:43:11 myhost kernel: [<ffffffff81044a8d>] ? kvm_clock_read+0x1b/0x1d Mar 7 02:43:11 myhost kernel: [<ffffffff8110f5a1>] ? __raw_callee_save___pv_queued_spin_unlock+0x11/0x1e Mar 7 02:43:11 myhost kernel: [<ffffffff81183316>] ? oom_kill_process+0xc0/0x34f Mar 7 02:43:11 myhost kernel: [<ffffffff811839b2>] ? out_of_memory+0x3bf/0x406 Mar 7 02:43:11 myhost kernel: [<ffffffff81187bbd>] ? __alloc_pages_nodemask+0x8ba/0x9d8 Mar 7 02:43:11 myhost kernel: [<ffffffff811b82e8>] ? alloc_pages_current+0xbc/0xe0 Mar 7 02:43:11 myhost kernel: [<ffffffff811b096c>] ? __vmalloc_node_range+0x12d/0x20a Mar 7 02:43:11 myhost kernel: [<ffffffff811e0e62>] ? alloc_fdtable+0x6a/0xd8 Mar 7 02:43:11 myhost kernel: [<ffffffff811b0a83>] ? __vmalloc_node+0x3a/0x3f Mar 7 02:43:11 myhost kernel: [<ffffffff811e0e62>] ? alloc_fdtable+0x6a/0xd8 Mar 7 02:43:11 myhost kernel: [<ffffffff811b0ab0>] ? vmalloc+0x28/0x2a Mar 7 02:43:11 myhost kernel: [<ffffffff811e0e62>] ? alloc_fdtable+0x6a/0xd8 Mar 7 02:43:11 myhost kernel: [<ffffffff811e1338>] ? dup_fd+0x103/0x1f0 Mar 7 02:43:11 myhost kernel: [<ffffffff810dd143>] ? copy_process+0x5aa/0x160d Mar 7 02:43:11 myhost kernel: [<ffffffff8110f5a1>] ? __raw_callee_save___pv_queued_spin_unlock+0x11/0x1e Mar 7 02:43:11 myhost kernel: [<ffffffff810de2fc>] ? _do_fork+0x7d/0x291 Mar 7 02:43:11 myhost kernel: [<ffffffff810ea186>] ? __set_current_blocked+0x47/0x52 Mar 7 02:43:11 myhost kernel: [<ffffffff810ea1f2>] ? sigprocmask+0x61/0x6a Mar 7 02:43:11 myhost kernel: [<ffffffff81998eae>] ? entry_SYSCALL_64_fastpath+0x12/0x71 Mar 7 02:43:11 myhost kernel: Mem-Info: Mar 7 02:43:11 myhost kernel: active_anon:15 inactive_anon:18 isolated_anon:0 Mar 7 02:43:11 myhost kernel: active_file:7 inactive_file:8 isolated_file:0 Mar 7 02:43:11 myhost kernel: unevictable:0 dirty:3 writeback:26 unstable:0 Mar 7 02:43:11 myhost kernel: slab_reclaimable:1798 slab_unreclaimable:3674 Mar 7 02:43:11 myhost kernel: mapped:8 shmem:1 pagetables:752 bounce:0 Mar 7 02:43:11 myhost kernel: free:1973 free_pcp:0 free_cma:0 Mar 7 02:43:11 myhost kernel: Node 0 DMA free:3944kB min:60kB low:72kB high:88kB active_anon:0kB inactive_anon:0kB active_file:28kB inactive_file:32kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15992kB managed:15908kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:72kB slab_unreclaimable:236kB kernel_stack:48kB pagetables:60kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:36 0 all_unreclaimable? yes Mar 7 02:43:11 myhost kernel: lowmem_reserve[]: 0 972 972 972 Mar 7 02:43:11 myhost kernel: Node 0 DMA32 free:3948kB min:3956kB low:4944kB high:5932kB active_anon:60kB inactive_anon:72kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:1032064kB manag ed:999552kB mlocked:0kB dirty:12kB writeback:104kB mapped:32kB shmem:4kB slab_reclaimable:7120kB slab_unreclaimable:14460kB kernel_stack:2112kB pagetables:2948kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_t mp:0kB pages_scanned:792 all_unreclaimable? yes Mar 7 02:43:11 myhost kernel: lowmem_reserve[]: 0 0 0 0 Mar 7 02:43:11 myhost kernel: Node 0 DMA: 20*4kB (UM) 17*8kB (UM) 13*16kB (M) 14*32kB (UM) 8*64kB (UM) 4*128kB (M) 4*256kB (M) 0*512kB 1*1024kB (M) 0*2048kB 0*4096kB = 3944kB Mar 7 02:43:11 myhost kernel: Node 0 DMA32: 934*4kB (UM) 28*8kB (UM) 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 3960kB Mar 7 02:43:11 myhost kernel: 71 total pagecache pages Mar 7 02:43:11 myhost kernel: 42 pages in swap cache Mar 7 02:43:11 myhost kernel: Swap cache stats: add 245190, delete 245148, find 77026/136093 Mar 7 02:43:11 myhost kernel: Free swap = 3118172kB Mar 7 02:43:11 myhost kernel: Total swap = 3334140kB Mar 7 02:43:11 myhost kernel: 262014 pages RAM Mar 7 02:43:11 myhost kernel: 0 pages HighMem/MovableOnly Mar 7 02:43:11 myhost kernel: 8149 pages reserved Mar 7 02:43:11 myhost kernel: [ pid ] uid tgid total_vm rss nr_ptes nr_pmds swapents oom_score_adj name Mar 7 02:43:11 myhost kernel: [ 2054] 0 2054 5101 1 15 4 283 0 upstart-udev-br Mar 7 02:43:11 myhost kernel: [ 2063] 0 2063 12362 1 28 4 184 -1000 systemd-udevd Mar 7 02:43:11 myhost kernel: [ 3342] 102 3342 9780 1 23 3 89 0 dbus-daemon Mar 7 02:43:11 myhost kernel: [ 3423] 0 3423 10864 1 26 3 85 0 systemd-logind Mar 7 02:43:11 myhost kernel: [ 3441] 0 3441 15344 0 34 3 184 -1000 sshd Mar 7 02:43:11 myhost kernel: [ 3450] 0 3450 4786 0 14 3 43 0 atd Mar 7 02:43:11 myhost kernel: [ 3451] 0 3451 5915 0 17 4 65 0 cron Mar 7 02:43:11 myhost kernel: [ 3457] 101 3457 63962 0 28 3 202 0 rsyslogd Mar 7 02:43:11 myhost kernel: [ 3516] 0 3516 3919 1 13 3 156 0 upstart-file-br Mar 7 02:43:11 myhost kernel: [ 3518] 0 3518 4014 0 13 3 265 0 upstart-socket- Mar 7 02:43:11 myhost kernel: [ 3557] 0 3557 66396 0 32 3 1802 0 fail2ban-server Mar 7 02:43:11 myhost kernel: [ 3600] 0 3600 3956 1 13 3 39 0 getty Mar 7 02:43:11 myhost kernel: [ 3601] 0 3601 3198 1 12 3 37 0 getty Mar 7 02:43:11 myhost kernel: [ 3673] 0 3673 26411 1 55 3 252 0 sshd Mar 7 02:43:11 myhost kernel: [ 3740] 1000 3740 26411 1 52 3 253 0 sshd Mar 7 02:43:11 myhost kernel: [ 3741] 1000 3741 5561 0 16 3 431 0 bash Mar 7 02:43:11 myhost kernel: [ 3820] 103 3820 7863 1 21 3 152 0 ntpd Mar 7 02:43:11 myhost kernel: [ 3837] 1000 3837 31990 0 58 4 12664 0 memcheck-AMD64- Mar 7 02:43:11 myhost kernel: [ 3841] 1000 3841 32006 0 59 4 12812 0 memcheck-AMD64- Mar 7 02:43:11 myhost kernel: [ 3844] 1000 3844 31950 0 57 4 12035 0 memcheck-AMD64- Mar 7 02:43:11 myhost kernel: [ 3849] 1000 3849 31902 0 56 4 11482 0 memcheck-AMD64- Mar 7 02:43:11 myhost kernel: [ 3853] 1000 3853 1087 0 7 3 27 0 lsof Mar 7 02:43:11 myhost kernel: [ 3854] 0 3854 26140 5 55 3 230 0 sshd Mar 7 02:43:11 myhost kernel: [ 3855] 104 3855 15699 0 33 3 202 0 sshd Mar 7 02:43:11 myhost kernel: Out of memory: Kill process 3841 (memcheck-AMD64-) score 11 or sacrifice child Mar 7 02:43:11 myhost kernel: Killed process 3841 (memcheck-AMD64-) total-vm:128024kB, anon-rss:0kB, file-rss:0kB

これは/ proc/meminfoです

MemTotal: 1015460 kB MemFree: 277508 kB MemAvailable: 322032 kB Buffers: 8336 kB Cached: 42208 kB SwapCached: 46088 kB Active: 58844 kB Inactive: 116100 kB Active(anon): 34784 kB Inactive(anon): 89620 kB Active(file): 24060 kB Inactive(file): 26480 kB Unevictable: 0 kB Mlocked: 0 kB SwapTotal: 3334140 kB SwapFree: 3215756 kB Dirty: 16 kB Writeback: 0 kB AnonPages: 121128 kB Mapped: 15072 kB Shmem: 4 kB Slab: 22668 kB SReclaimable: 8028 kB SUnreclaim: 14640 kB KernelStack: 2016 kB PageTables: 2532 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 3841868 kB Committed_AS: 380460 kB VmallocTotal: 34359738367 kB VmallocUsed: 0 kB VmallocChunk: 0 kB DirectMap4k: 14208 kB DirectMap2M: 1034240 kB DirectMap1G: 0 kB

Matthew Ife · Answer

これは、次の2つの要因の組み合わせで問題になるようです。

仮想マシンを使用する。
カーネルのバグの可能性があります。

これは、これが発生する理由を説明する行の一部です。

 3月7日02:43:11 myhostカーネル：memcheck-AMD64-呼び出されたoom-killer：gfp_mask = 0x24002c2、order = 0、oom_score_adj = 0

他の行はこれです：

Mar 7 02:43:11 myhost kernel: 0 pages HighMem/MovableOnly

|最初の行は、割り当てに割り当てられたGFPマスクです。これは基本的に、この要求を満足させるためにカーネルが実行できる/許可されていないことを記述しています。マスクは一連の標準フラグを示します。ただし、最後のビット「2」は、メモリ割り当てがHighMemゾーンからのものであることを示しています。

OOMの出力をよく見ると、実際にはHighMem/Normalゾーンが存在しないことがわかります。

Mar 7 02:43:11 myhost kernel: Node 0 DMA: 20*4kB (UM) 17*8kB (UM) 13*16kB (M) 14*32kB (UM) 8*64kB (UM) 4*128kB (M) 4*256kB (M) 0*512kB 1*1024kB (M) 0*2048kB 0*4096kB = 3944kB Mar 7 02:43:11 myhost kernel: Node 0 DMA32: 934*4kB (UM) 28*8kB (UM) 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 3960kB

HighMem（x86_64では一般にNormalとも呼ばれます）は、32ビットシステムでカーネルに直接アクセスできる標準の896MiB範囲外のゾーンのメモリをマップする傾向があります。 x86_64では、HighMem/Normalはサイズが3GiBを超えるすべてのページをカバーしているようです。

DMA32には、32ビットデバイスでアクセス可能なメモリ用に使用されるゾーンが含まれていますDMAデバイス、つまり、4バイトのポインタでアドレス指定できます。DMA 16ビットDMAデバイス用です。

一般的に言えば、DMA32がすべての利用可能な仮想アドレスをすでにカバーしていることを考えると、低メモリシステムではNormalは存在しません。

OOMを強制終了する理由は、使用可能なページが0のHighMemゾーンにメモリが割り当てられているためです。メモリー不足ハンドラーは、このゾーンにスワッピング、他のプロセスまたは他のトリックを強制終了することで使用するページを作成することを完全に満足させる方法がないため、OOM-killerは単に強制終了します。

これは、ホストVM起動時のバルーニングが原因であると考えています。KVMシステムでは、2つの値を設定できます。

現在のメモリ。
利用可能なメモリ。

これが機能する方法は、使用可能なメモリまでサーバーにメモリをホット追加できることです。ただし、実際にはシステムに現在のメモリが割り当てられています。

KVM VMが起動するとき、それは、与えられる可能性のある最大のメモリ割り当て（使用可能なメモリ）から始まります。 system KVMは、バルーニングを使用してこのメモリをクローバックし、代わりに現在のメモリ設定を保持します。

私の信念は、ここで何が起こったかです。 Linodeはメモリを拡張することを可能にし、システムの起動時にはるかに多くを与えます。

これは、システムのライフタイムの初めにNormal/HighMemゾーンがあることを意味します。ハイパーバイザーがそれを膨らませると、通常のゾーンがメモリマネージャーから正しく消えます。しかし、そのゾーンが割り当て可能かどうかのフラグ設定は、必要なときにnotがクリアされていると思います。これにより、カーネルは存在しないゾーンから割り当てを試みます。

これを解決するには、2つのオプションがあります。

これをカーネルのメーリングリストに載せて、これが本当にバグなのか、予想される動作なのか、私が言っていることとは何の関係もないのかどうかを確認してください。
Linodeがシステムの「利用可能なメモリ」を「現在のメモリ」と同じ1GiB割り当てに設定するように要求します。したがって、フラグがクリアされたままになっていると、システムは起動時に膨張することはなく、起動時に通常ゾーンを取得することもありません。幸運を祈ります！

独自のVM in KVM利用可能な6GiB、現在の1GiBに設定し、次を使用してテストを実行することにより、これが当てはまることをテストできるはずです。同じカーネルで上記の動作が発生するかどうかを確認します。発生する場合は、「利用可能」設定を1GiB電流に等しくなるように変更し、テストを繰り返します。

私はここで多くの知識に基づいた推測を行い、この答えを思い付くために行の間を少し読んでいますが、私が言っていることはすでに概説された事実に適合しているようです。

私は私の仮説をテストして、私たち全員に結果を知らせることを勧めます。

user9517 · Answer

見出しの質問に答えるには、oom_score_adj（kernel> = 2.6.36）を使用するか、以前のカーネル（> = 2.6.11）oom_adjの場合は、man proc を参照してください

/ proc/[pid]/oom_score_adj（Linux 2.6.36以降）このファイルを使用して、メモリ不足の状態で強制終了するプロセスを選択するために使用される不良ヒューリスティックを調整できます...

/ proc/[pid]/oom_adj（Linux 2.6.11以降）このファイルを使用して、メモリ不足（OOM）の状況で強制終了するプロセスを選択するために使用されるスコアを調整できます...

読むべきことは他にもたくさんありますが、oom_score_adjを-1000に、またはoom_adjを-17に設定すると、期待どおりの結果が得られます。

問題は他の何かが殺されることです。おそらく、なぜOOMが呼び出されているのかを判断し、それを処理する方が良いでしょう。

Olivier Dulac · Answer

（上記の私のコメントからの）いくつかの考えと、あなたの状況についての興味深い読みへのリンク：

1）現在のカーネルと構成（＆cpu）で3Gb以上に対処できることを確認することをお勧めします[3GbがシステムとOSの制限である場合、それを超えているため]。 2）スワッピングを許可し、スワッピングサブシステムが適切に機能していること。幸運を祈ります（設定や詳細によって異なります。検索エンジンが役立ちます）。また、カーネルテーブル（pidのnb？など）がオーバーフローしていないことも確認してください（カーネルのコンパイル時に設定できる場合もあります）。
全体（ハードウェア、またはvmのシミュレートされたハードウェアなど）が64ビットであることを確認します。（例を参照： https://askubuntu.com/questions/313379/i-installed-a-64-bit-os-in-a-32-bit-processor/313381 ）。 CPUとホストOSとVMサブシステムとVM OSはすべて64ビット対応である必要があります。そうでない場合、実際の64ビットVMはありません。
良い読み物：
そして最後に： http://www.Oracle.com/technetwork/articles/servers-storage-dev/oom-killer-1911807.html は、プロセスがoomのターゲットにならないようにする方法を示していますキラー！（echo -17 > /proc/PROCESSPID/oom_adj）。変更される傾向がある可能性があり、悪いことになる可能性があります（他の種類の障害が原因で、システムは主な攻撃者を単に殺すことができないため...）注意して使用してください。 @iainは、「oom_adj」は古いカーネル用であり、新しいカーネルでは「oom_score_adj」に置き換える必要があることに注意してください。ありがとう、イアン）

Matija Nalis · Answer

問題のプロセスの増加oom_score_adjは増加します（おそらくあまり役に立たないでしょう-そのプロセスが最初に強制終了される可能性は低くなりますが、それはメモリ集中型のプロセスシステムのみであるため、おそらくそれが最終的に殺されるまで回復します）、ここに調整するいくつかのアイデアがあります：

vm.overcommit_memory=2を設定した場合は、vm.overcommit_ratioも90に調整します（または、vm.overcommit_memory=0を設定します- kernel overcommit docs を参照）。
常にいくつかの物理的なRAMを空けておくためにvm.min_free_kbytesを増やし、したがって、OOMが何かを強制終了する必要がある可能性を減らします（ただし、OOMは即座に実行されるため、無理しないでください）。
vm.swappinessを100に増やします（カーネルスワップをより簡単にするにするため）。

メモリが少なすぎて手元のタスクを実行できない場合は、OOMを実行していなくても、可能性があります（または可能性がない）非常に遅くなることに注意してください-十分なRAMを備えたシステムでの30分ジョブは、極端な場合に完了するまでに数週間（RAMがswapで置き換えられた場合）で完了するか、VM全体がハングすることさえあります。特に、それらが非常に高価である大規模なランダム読み取り/書き込みが原因で、スワップが（SSDではなく）古典的な回転ディスク上にある場合。

Dmitry Grigoryev · Answer

オーバーコミットを有効にして、それが役立つかどうかを確認します。プロセスはfork呼び出し内で失敗するようです。この呼び出しには、初期プロセスと同じ量の仮想メモリが必要です。 overcommit_memory=2は、プロセスがOOMキラーの影響を受けないようにするのではなく、割り当てすぎてプロセスがトリガーされないようにするだけです。他のプロセスは、関連しない割り当てエラー（連続するメモリブロックの取得など）を生成する可能性があり、それでもOOMキラーがトリガーされ、プロセスが破棄されます。

代わりに（そして要点はさらに）、いくつかのコメントが示唆するように、より多くのRAMを購入します。

user367995 · Answer

ショートストーリー-別のカーネルバージョンを試してください。 4.2.0-xおよび4.4.0-xカーネルでOOMエラーを表示したが、3.19.0-xでは表示しないシステムがあります。

長い話：（あまり長くはありません！）Compaq DC5000をまだここで使用しています-現在512MBのRAM（および32-128MBのような、その一部が提供されています）オンボードビデオに..）ほとんどの場合、NFSにサービスを提供していますが、モニターに接続しているため、時々ログインします（Ubuntu Classic、Unityではありません）。

Ubuntu HWEを使用して、しばらくの間3.19.xカーネルを実行していました。 200-300MBのようにスワップアウトすることになりますが、それは未使用のものでした。私が知る限り、それを後でスワップしなければならないことによるスワップアクティビティはありません。

4.2.0-xカーネルと4.4.0-xカーネルでは、NFSに分厚い書き込みを開始できます。スワップに220MB（つまり1.3GBの空き容量）を追加するだけで、OOMが起動しなくなります。カーネルのバグなのか「チューニングの問題」なのかは主張しません（64MBの予約は通常問題ありませんが、400MB程度のシステムでは高すぎるのでしょうか？）

彼がスワップを使用することを期待しているからといって、それがどういうわけか壊れていると言っている人を軽視しません。すべての敬意をもってあなたは間違っています。それは速くはありませんが、私はいくつかの512MB-1GBシステムのスワップに1または2GBを使用していました。もちろん、一部のタイプのソフトウェアmlockはRAMの束ですが、私の場合（同じソフトウェアを別のカーネルで実行しているため）これは明らかにそうではありません。