Linux OOMキラーを取得してプロセスを強制終了しないようにするにはどうすればよいですか？

28

物理メモリが少ないがスワップスペースが十分にあるときにLinux OOMキラーを使用してプロセスを強制終了しないようにするにはどうすればよいですか？

sysctl vm.overcommit_memory = 2でOOMの強制終了とオーバーコミットを無効にしました。

VMには3 GBの完全に無料の断片化されていないスワップがあり、OOMを強制終了するプロセスの最大メモリ使用量は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

linux swap oom

— コーダー
ソース

8

呼び出しトレースから、カーネルに十分なメモリがなかったことは明白です。スワップしなかった理由については、多くの異なる原因が考えられますが、それらはすべて500文字で完全に説明するには長すぎます。ただし、再生可能なページがなかったようです（all_unreclaimableはい）。これらはRAMにロックされたページです。これは一般に、固定されているかカーネルによって使用されているためです。その時点でRAMに残っていたものは交換できませんでした。スワップアウトできた可能性のあるものはすべて既に使用されていました。繰り返しますが、ソリューションはより多くのRAMです。

— マイケルハンプトン

1

@MichaelHampton残りのメモリは、通常のアプリケーションによって使用されています。なぜカーネルはそれらをスワップにプッシュできないのですか？「あなたの言っていることが本当なら、すべての物理メモリが使用された後、どのプロセスが分岐するのでしょうか？」という私の質問に答えてください。

— コーダー

1

@MichaelHamptonフォークを無効にすると、fail2banがoom killerを呼び出して、プロセスが強制終了されます。カーネルがスワップを使用しない場合、スワップを使用する意味は何ですか？さらに重要なのは、メモリ不足を防ぐためにカーネルをどのように構成するかです。

— コーダー

4

@MatthewIfe：答えがわかっている場合は、ここに投稿してください。Stack Exchangeサイトは、質問をしたOPだけでなく、読むすべての人のためにあります。

— R ..

4

VMでのスワップはベストプラクティスとは見なされません。VMにより多くの実メモリを割り当てます。メモリを追加できない場合は、十分なサイズのレンタルではなく、物理ハードウェアに社内で持ち込みます。

— クリギー

36

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

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

これは、これが起こる理由を説明する行の一部です：

3月7日02:43:11 myhostカーネル：memcheck-amd64- invoke 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（一般的Normalにx86_64 とも呼ばれます）32ビットシステムでカーネルが直接アクセスできる標準の896MiB範囲外のゾーンのメモリをマップする傾向があります。x86_64 HighMem/Normalでは、サイズが3GiBを超えるすべてのページをカバーしているようです。

DMA3232ビットDMAデバイスでアクセス可能なメモリに使用されるゾーンが含まれています。つまり、4バイトポインターでアドレス指定できます。DMA16ビットDMAデバイス向けだと思います。

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

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

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

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

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

KVM VMが起動すると、与えられるメモリの最大割り当て（使用可能なメモリ）から開始します。システムのブートフェーズ中、KVMはバルーニングを使用してこのメモリを徐々に戻し、代わりに現在のメモリ設定を使用します。

私の信念は、ここで何が起こったかです。Linodeを使用すると、メモリを拡張して、システムの起動時にさらに多くの情報を提供できます。

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

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

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

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

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

仮説を検証し、結果を全員に知らせることをお勧めします。

— マシュー・イフェ
ソース

4

それは完全な（そして十分に説明された）答えです！

— オリビエデュラック

2

はい、素晴らしい答えです...利用可能なスワップ領域が使用されていない理由を説明することなく、「OPはカーネルメッセージを盲目的に信頼するべきである」という人々のコメントよりもはるかに役立ちます。

— マイケルマルティネス

31

、使用あなたの見出しの質問に答えるためにoom_score_adj（カーネル> = 2.6.36）以前のカーネル（> = 2.6.11）のためにoom_adj、男性の参照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が呼び出されている理由を特定し、対処する方が良いでしょう。

— user9517はGoFundMonicaをサポートしています
ソース

4

「根本的な問題を解決する」ための+1。問題のソフトウェア（または他の何か）がコアの大きなチャンクをmallocしようとした可能性はありますか？OOMキラーをトリガーする傾向がある、より多くのメモリの要求、つまり、物事をレッドアラートの領域に持ち込むための要求です。

— MadHatterは、Monica

11

@Coder：LinuxカーネルプログラマーとLinuxカーネルは、明らかにあなた以上のことを知っています。（抗議にもかかわらず）メモリが不足していたため、プロセスが強制終了されました。これが間違っていると思われる場合は、バグレポートを提出してください。明確な知識のある人の発言に耳を傾けるつもりがない場合は、アドバイスに値する価値があるので、おそらくサポートにお金を払う必要があります。アドバイスは変わりませんが、あなたはそれを支払ったでしょうので、それをより大切にします。

— user9517はGoFundMonica

4

@Coder残念ながら、私はプログラマーではありません。カーネルがVMの使用方法を知らないことと、プログラマーがエラーを犯したこと、2つの可能性の間に挟まれていることです。

— MadHatterは、Monica

1

@coder私は「誰か」です。連絡方法を教えてください。

— マシューイフェ

1

数千のLinuxシステムを実行している@MadHatterから言えることですが、メモリ管理やカーネルの他の部分に問題がないと仮定できるわけではありません。これは、ハイグレードなUNIXプラットフォームとは異なり、通常はすべて正常に動作しますが、独断的な方法でどちらの側をとっても賢明ではありません。

— フロリアンハイグル

12

いくつかの考え（上記の私のコメントから）、およびあなたの状況に関する興味深い読み物へのリンク：

1）現在のカーネルと設定（＆cpu）で3Gb以上をアドレスできることを確認することをお勧めします[3GbがシステムとOSの制限である場合、それを超えているため]。2）スワップを許可し、スワップサブシステムが適切に機能していること。幸運を祈ります（設定と仕様に依存するため、方法については説明しません。検索エンジンが役立ちます）。また、カーネルテーブル（nbのpids？など）をオーバーフローさせていないこと（カーネルのコンパイル時に設定できるものもあります）。
全体（ハードウェア、または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はありません
良い読み物：
- oom-killerの強制終了プロセスの原因を診断する方法：このサイトで。素敵なリンクhttp://linux-mm.org/OOM_Killerを提供し、別のユーザーがatopツールを紹介します。これは何が起こるかを診断するのに役立ちます
- https://www.kernel.org/doc/gorman/html/understand/understand016.html：3.12は、OOMの決定ツリーを示しています（古いバージョンなので、ymmv。ソースを読んでください^^）
- https://lwn.net/Articles/317814/：「OOMキラーを飼いならす」は、とりわけ、「インビシブル」グループを作成してプロセスを配置する方法を示しています。
- http://eloquence.marxmeier.com/sdb/html/linux_limits.html：一般的なカーネルの制限を示しています
- http://win.tue.nl/~aeb/linux/lk/lk-9.html：本当に古くなっています（したがって、32のみをアドレス指定していますが）ビットアーキテクチャ...）
- http://bl0rg.krunch.be/oom-frag.htmlは、「使用可能なメモリが十分にある場合でもOOMキラーが呼び出される可能性がある」理由を示しています
- https://stackoverflow.com/questions/17935873/malloc-fails-when-there-is-still-plenty-of-swap-left：システムがメモリを割り当てる方法を確認する方法を提供します
- https://serverfault.com/a/724518/146493：実際に何が起こったのかを詳細に知るための優れた回答（ただし... 32ビットの質問をターゲットにしたので、ymmv。まだ信じられないほどの読みと回答）
そして最後に：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」に置き換える必要があることに注意してください。ありがとう、イアン）

— オリヴィエ・デュラック
ソース

1

oom_adjは古いカーネルにのみ有効で、新しいカーネルはoom_score_adjを使用します。

— user9517は

免責事項：現時点ではLinuxシステムにアクセスできないため、上記のいくつかのリンクよりも詳細な情報を提供することはできません...確認することが非常に多くあります。たぶん誰かが介入して素敵なステップバイステップの手順を提供します...（サーバーフォールトの答え、私の答えの「良い読み取り」リンクの最後は、そのようなもので、信じられないほどの読み取りです。）

— オリビエデュラック

6

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

を設定した場合はvm.overcommit_memory=2、vm.overcommit_ratio90に調整することもできます（または、設定vm.overcommit_memory=0- カーネルオーバーコミットドキュメントを参照してください））
増加する vm.min_free_kbytesは常に自由ないくつかの物理RAMを保つため、何かを殺すために（それが瞬時にOOMうとして、無理をしないでください）必要OOMの可能性を減らすためです。
vm.swappiness100に増やします（カーネルスワップをより簡単にするため）

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

— マティヤ・ナリス
ソース

3

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

別の方法で（さらに重要なことですが）、いくつかのコメントが示唆するように、RAMを追加購入してください。

— ドミトリー・グリゴリエフ
ソース

0

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

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

Ubuntu HWEを介して、しばらくの間3.19.xカーネルを実行していました。最終的には200-300MBのようなものがスワップアウトされますが、明らかにそれは未使用のものでした。私が知る限り、それを後でスワップインすることからのスワップ活動はありません。

4.2.0-xカーネルと4.4.0-xカーネル、これにチャンキーNFS書き込みを開始できます。スワップに220MBのみ（つまり1.3GB空き）で、OOMが強制終了します。カーネルのバグまたは「チューニングの問題」（通常は問題ないが、〜400MB程度のシステムでは高すぎる64MBの予約など）であると主張するつもりはありません。

彼がスワップを使用することを期待しているという理由だけで、それが何らかの形で壊れていると言っている人たちに対する無礼はありません。すべての敬意を払ってあなたは間違っています。高速ではありませんが、以前はいくつかの512MB-1GBシステムで1GBまたは2GBをスワップに使用していました。もちろん、いくつかの種類のソフトウェアは大量のRAMを持っていますが、私の場合（同じソフトウェアを異なるカーネルで実行しているため）、明らかにそうではありません。

— user367995
ソース