Linux の oom 状況 (32 ビットカーネル)

Question 1

ただし、ゾーンのレイアウトが異なるため、64 ビット O/S (これは 32 ビット) にアップグレードするという「大胆な」アプローチが必要になります。

さて、ここで OOM が発生した理由についてお答えします。ここではいくつかの要因が関係しています。

リクエストの注文サイズとカーネルが特定の注文サイズを処理する方法。
選択されているゾーン。
このゾーンが使用する透かし。
ゾーン内の断片化。

OOM 自体を見ると、明らかに空きメモリがたくさんあるのに、OOM-killer が呼び出されました。なぜでしょうか?

リクエストの注文サイズとカーネルが特定の注文サイズをどのように処理するか

カーネルはメモリを順序に従って割り当てます。「順序」とは、リクエストが機能するために満たさなければならない連続した RAM の領域です。順序は、アルゴリズムを使用して大きさの順序 (したがって順序と呼ばれます) で並べられます2^(ORDER + 12)。したがって、順序 0 は 4096、順序 1 は 8192、順序 2 は 16384 というようになります。

カーネルには、「高位」(> PAGE_ALLOC_COSTLY_ORDER) と見なされるハードコードされた値があります。これは 4 位以上です (64kb 以上が高位です)。

ページの割り当てについては、高次順序は低次順序とは異なります。高次順序の割り当てでは、メモリの取得に失敗した場合、最新のカーネルではメモリの取得が行われます。

メモリをデフラグするためにメモリ圧縮ルーチンを実行してみてください。
一度もない要求を満たすために OOM-killer を呼び出します。

ご注文のサイズはここに記載されています

Dec 27 09:19:05 2013 kernel: : [277622.359064] squid invoked oom-killer: gfp_mask=0x42d0, order=3, oom_score_adj=0

順序 3 は低順序要求の中で最も高いものであり、(ご覧のとおり) それを満たすために OOM キラーを呼び出します。

ほとんどのユーザー空間割り当てでは高次リクエストは使用されないことに注意してください。通常、連続したメモリ領域を必要とするのはカーネルです。ユーザー空間が hugepages を使用している場合は例外となる可能性がありますが、ここではそうではありません。

あなたの場合、順序 3 の割り当ては、パケットをネットワークスタックにキューに入れようとするカーネルによって呼び出され、そのためには 32kb の割り当てが必要です。

選択されているゾーン。

カーネルはメモリ領域をゾーンに分割します。この分割は、x86では特定のメモリ領域が特定のハードウェアでのみアドレス指定可能であるために行われます。たとえば、古いハードウェアは「DMA」ゾーンのメモリしかアドレス指定できない場合があります。メモリを割り当てたい場合、まずゾーンが選択され、のみ割り当てを決定する際には、このゾーンの空きメモリが考慮されます。

ゾーン選択アルゴリズムについて完全には理解していませんが、一般的な使用例では DMA から割り当てることはなく、通常は要求を満たすことができる最も低いアドレス指定可能なゾーンを選択します。

OOM 中には大量のゾーン情報が吐き出され、からも収集できます/proc/zoneinfo。

Dec 27 09:19:05 2013 kernel: : [277622.359382] DMA free:2332kB min:36kB low:44kB high:52kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15968kB managed:6960kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:8kB slab_unreclaimable:288kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
Dec 27 09:19:05 2013 kernel: : [277622.359393] Normal free:114488kB min:3044kB low:3804kB high:4564kB active_anon:0kB inactive_anon:0kB active_file:252kB inactive_file:256kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:894968kB managed:587540kB mlocked:0kB dirty:0kB writeback:0kB mapped:4kB shmem:0kB slab_reclaimable:117712kB slab_unreclaimable:138616kB kernel_stack:11976kB pagetables:0kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:982 all_unreclaimable? yes
Dec 27 09:19:05 2013 kernel: : [277622.359404] HighMem free:27530668kB min:512kB low:48272kB high:96036kB active_anon:2634060kB inactive_anon:217596kB active_file:4688452kB inactive_file:1294168kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:36828872kB managed:36828872kB mlocked:0kB dirty:0kB writeback:0kB mapped:183132kB shmem:39400kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:430856kB unstable:0kB bounce:367564104kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no

DMA、Normal、HighMem の各ゾーンは 32 ビットプラットフォームを示しています。これは、HighMem ゾーンが 64 ビットには存在しないためです。また、64 ビットシステムでは、Normal は 4GB 以上にマップされますが、32 ビットでは最大 896Mb にマップされます (ただし、この場合、カーネルはこれよりも小さい部分のみを管理していると報告します:- managed:587540kB。)

最初の行をもう一度見れば、この割り当てがどこから来たのかがわかりますgfp_mask=0x42d0。割り当ての種類がわかります。最後のバイト (0) は、これが通常のゾーンからの割り当てであることを示しています。GFP の意味は、インクルード/linux/gfp.h。

このゾーンが使用する透かし。

メモリが少ない場合、それを再利用するためのアクションはウォーターマークによって指定されます。これらはここに表示されます: min:3044kB low:3804kB high:4564kB。空きメモリが「low」に達すると、「high」しきい値を超えるまでスワッピングが発生します。メモリが「min」に達すると、OOM-killer を介してメモリを解放するために、何かを強制終了する必要があります。

ゾーン内の断片化。

特定のメモリオーダーの要求が満たされるかどうかを確認するために、カーネルは各オーダーの空きページ数と使用可能ページ数を計算します。これはで確認できます/proc/buddyinfo。OOM-killer レポートでは、次に示すように、buddyinfo も出力されます。

Normal: 5360*4kB (UEM) 3667*8kB (UEM) 3964*16kB (UEMR) 13*32kB (MR) 0*64kB 1*128kB (R) 1*256kB (R) 0*512kB 0*1024kB 0*2048kB 0*4096kB = 115000kB

メモリ割り当てが満たされるためにはしなければならない要求されたオーダーサイズまたはより高い割り当てで空きメモリが利用可能である必要があります。下位オーダーに大量の空きデータがあり、上位オーダーに空きデータがない場合、メモリが断片化されていることを意味します。非常に高いオーダーの割り当てを取得すると、(空きメモリが大量にある場合でも) 上位ページが利用できないために満たされない可能性があります。カーネルは、アドレス指定可能な RAM スペースにギャップが残らないように、多数の下位オーダーページを移動することによってメモリをデフラグできます (これをメモリコンパクションと呼びます)。

OOM-killer が呼び出されましたか? なぜですか?

したがって、これらのことを考慮すると、次のことが言えます。

32kB の連続割り当てが試行されました。通常ゾーンから。
選択したゾーンには十分な空きメモリがありました。
3、5、6番目のメモリが利用可能でした13*32kB (MR) 1*128kB (R) 1*256kB (R)

だから、もしだった空きメモリ、その他の注文できた要求を満たします。何が起こったのですか?

そうですね、オーダーから割り当てるには、そのオーダー以上の使用可能な空きメモリの量をチェックするだけではありません。カーネルは、空きメモリの合計ラインからすべての下位オーダーのメモリを効果的に減算し、残ったメモリに対して最小ウォーターマークチェックを実行します。

あなたのケースでは、実行する必要があるゾーンの空きメモリを確認することになります。

115000 - (5360*4) - (3667*8) - (3964*16) = 800

この空きメモリの量は、ウォーターマーク (3044) に対してチェックされますmin。したがって、技術的に言えば、要求した割り当てを行うための空きメモリが残っていません。これが、OOM-killer を呼び出した理由です。

修正

修正方法は 2 つあります。64 ビットにアップグレードすると、ゾーンのパーティション分割が変更され、「通常」が 4 GB から 36 GB までになるため、メモリ割り当てが「デフォルト」になり、非常に断片化される可能性のあるゾーンに設定されることはありません。アドレス指定可能なメモリが増えたからといってこの問題が解決するわけではありません (PAE を既に使用しているため)。選択したゾーンのアドレス指定可能なメモリが増えるだけです。

2 番目の方法 (私はまだテストしていませんが) は、カーネルにメモリをより積極的に圧縮させることです。

の値をvm.extfrag_threshold500 から 100 に変更すると、高次の割り当てを尊重するためにメモリを圧縮する可能性が高くなります。ただし、この値はこれまで変更したことがありません。これは、で使用可能な断片化インデックスによっても異なります/sys/kernel/debug/extfrag/extfrag_index。現時点では、これ以上の性能を発揮できるほど新しいカーネルを搭載したボックスを所有していません。

あるいは、何らかの cron ジョブ (これは非常に醜い) を実行して、に書き込むことで手動でメモリを圧縮することもできます/proc/sys/vm/compact_memory。

しかし、正直に言うと、この問題を回避するためにシステムを調整する方法は実際にはないと思います。これはメモリアロケータがこのように動作することの性質によるものです。使用しているプラットフォームのアーキテクチャを変更することが、おそらく唯一の根本的な解決方法です。

Answer

ただし、ゾーンのレイアウトが異なるため、64 ビット O/S (これは 32 ビット) にアップグレードするという「大胆な」アプローチが必要になります。

さて、ここで OOM が発生した理由についてお答えします。ここではいくつかの要因が関係しています。

リクエストの注文サイズとカーネルが特定の注文サイズを処理する方法。
選択されているゾーン。
このゾーンが使用する透かし。
ゾーン内の断片化。

OOM 自体を見ると、明らかに空きメモリがたくさんあるのに、OOM-killer が呼び出されました。なぜでしょうか?

リクエストの注文サイズとカーネルが特定の注文サイズをどのように処理するか

カーネルはメモリを順序に従って割り当てます。「順序」とは、リクエストが機能するために満たさなければならない連続した RAM の領域です。順序は、アルゴリズムを使用して大きさの順序 (したがって順序と呼ばれます) で並べられます2^(ORDER + 12)。したがって、順序 0 は 4096、順序 1 は 8192、順序 2 は 16384 というようになります。

カーネルには、「高位」(> PAGE_ALLOC_COSTLY_ORDER) と見なされるハードコードされた値があります。これは 4 位以上です (64kb 以上が高位です)。

ページの割り当てについては、高次順序は低次順序とは異なります。高次順序の割り当てでは、メモリの取得に失敗した場合、最新のカーネルではメモリの取得が行われます。

メモリをデフラグするためにメモリ圧縮ルーチンを実行してみてください。
一度もない要求を満たすために OOM-killer を呼び出します。

ご注文のサイズはここに記載されています

Dec 27 09:19:05 2013 kernel: : [277622.359064] squid invoked oom-killer: gfp_mask=0x42d0, order=3, oom_score_adj=0

順序 3 は低順序要求の中で最も高いものであり、(ご覧のとおり) それを満たすために OOM キラーを呼び出します。

ほとんどのユーザー空間割り当てでは高次リクエストは使用されないことに注意してください。通常、連続したメモリ領域を必要とするのはカーネルです。ユーザー空間が hugepages を使用している場合は例外となる可能性がありますが、ここではそうではありません。

あなたの場合、順序 3 の割り当ては、パケットをネットワークスタックにキューに入れようとするカーネルによって呼び出され、そのためには 32kb の割り当てが必要です。

選択されているゾーン。

カーネルはメモリ領域をゾーンに分割します。この分割は、x86では特定のメモリ領域が特定のハードウェアでのみアドレス指定可能であるために行われます。たとえば、古いハードウェアは「DMA」ゾーンのメモリしかアドレス指定できない場合があります。メモリを割り当てたい場合、まずゾーンが選択され、のみ割り当てを決定する際には、このゾーンの空きメモリが考慮されます。

ゾーン選択アルゴリズムについて完全には理解していませんが、一般的な使用例では DMA から割り当てることはなく、通常は要求を満たすことができる最も低いアドレス指定可能なゾーンを選択します。

OOM 中には大量のゾーン情報が吐き出され、からも収集できます/proc/zoneinfo。

Dec 27 09:19:05 2013 kernel: : [277622.359382] DMA free:2332kB min:36kB low:44kB high:52kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15968kB managed:6960kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:8kB slab_unreclaimable:288kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
Dec 27 09:19:05 2013 kernel: : [277622.359393] Normal free:114488kB min:3044kB low:3804kB high:4564kB active_anon:0kB inactive_anon:0kB active_file:252kB inactive_file:256kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:894968kB managed:587540kB mlocked:0kB dirty:0kB writeback:0kB mapped:4kB shmem:0kB slab_reclaimable:117712kB slab_unreclaimable:138616kB kernel_stack:11976kB pagetables:0kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:982 all_unreclaimable? yes
Dec 27 09:19:05 2013 kernel: : [277622.359404] HighMem free:27530668kB min:512kB low:48272kB high:96036kB active_anon:2634060kB inactive_anon:217596kB active_file:4688452kB inactive_file:1294168kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:36828872kB managed:36828872kB mlocked:0kB dirty:0kB writeback:0kB mapped:183132kB shmem:39400kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:430856kB unstable:0kB bounce:367564104kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no

DMA、Normal、HighMem の各ゾーンは 32 ビットプラットフォームを示しています。これは、HighMem ゾーンが 64 ビットには存在しないためです。また、64 ビットシステムでは、Normal は 4GB 以上にマップされますが、32 ビットでは最大 896Mb にマップされます (ただし、この場合、カーネルはこれよりも小さい部分のみを管理していると報告します:- managed:587540kB。)

最初の行をもう一度見れば、この割り当てがどこから来たのかがわかりますgfp_mask=0x42d0。割り当ての種類がわかります。最後のバイト (0) は、これが通常のゾーンからの割り当てであることを示しています。GFP の意味は、インクルード/linux/gfp.h。

このゾーンが使用する透かし。

メモリが少ない場合、それを再利用するためのアクションはウォーターマークによって指定されます。これらはここに表示されます: min:3044kB low:3804kB high:4564kB。空きメモリが「low」に達すると、「high」しきい値を超えるまでスワッピングが発生します。メモリが「min」に達すると、OOM-killer を介してメモリを解放するために、何かを強制終了する必要があります。

ゾーン内の断片化。

特定のメモリオーダーの要求が満たされるかどうかを確認するために、カーネルは各オーダーの空きページ数と使用可能ページ数を計算します。これはで確認できます/proc/buddyinfo。OOM-killer レポートでは、次に示すように、buddyinfo も出力されます。

Normal: 5360*4kB (UEM) 3667*8kB (UEM) 3964*16kB (UEMR) 13*32kB (MR) 0*64kB 1*128kB (R) 1*256kB (R) 0*512kB 0*1024kB 0*2048kB 0*4096kB = 115000kB

メモリ割り当てが満たされるためにはしなければならない要求されたオーダーサイズまたはより高い割り当てで空きメモリが利用可能である必要があります。下位オーダーに大量の空きデータがあり、上位オーダーに空きデータがない場合、メモリが断片化されていることを意味します。非常に高いオーダーの割り当てを取得すると、(空きメモリが大量にある場合でも) 上位ページが利用できないために満たされない可能性があります。カーネルは、アドレス指定可能な RAM スペースにギャップが残らないように、多数の下位オーダーページを移動することによってメモリをデフラグできます (これをメモリコンパクションと呼びます)。

OOM-killer が呼び出されましたか? なぜですか?

したがって、これらのことを考慮すると、次のことが言えます。

32kB の連続割り当てが試行されました。通常ゾーンから。
選択したゾーンには十分な空きメモリがありました。
3、5、6番目のメモリが利用可能でした13*32kB (MR) 1*128kB (R) 1*256kB (R)

だから、もしだった空きメモリ、その他の注文できた要求を満たします。何が起こったのですか?

そうですね、オーダーから割り当てるには、そのオーダー以上の使用可能な空きメモリの量をチェックするだけではありません。カーネルは、空きメモリの合計ラインからすべての下位オーダーのメモリを効果的に減算し、残ったメモリに対して最小ウォーターマークチェックを実行します。

あなたのケースでは、実行する必要があるゾーンの空きメモリを確認することになります。

115000 - (5360*4) - (3667*8) - (3964*16) = 800

この空きメモリの量は、ウォーターマーク (3044) に対してチェックされますmin。したがって、技術的に言えば、要求した割り当てを行うための空きメモリが残っていません。これが、OOM-killer を呼び出した理由です。

修正

修正方法は 2 つあります。64 ビットにアップグレードすると、ゾーンのパーティション分割が変更され、「通常」が 4 GB から 36 GB までになるため、メモリ割り当てが「デフォルト」になり、非常に断片化される可能性のあるゾーンに設定されることはありません。アドレス指定可能なメモリが増えたからといってこの問題が解決するわけではありません (PAE を既に使用しているため)。選択したゾーンのアドレス指定可能なメモリが増えるだけです。

2 番目の方法 (私はまだテストしていませんが) は、カーネルにメモリをより積極的に圧縮させることです。

の値をvm.extfrag_threshold500 から 100 に変更すると、高次の割り当てを尊重するためにメモリを圧縮する可能性が高くなります。ただし、この値はこれまで変更したことがありません。これは、で使用可能な断片化インデックスによっても異なります/sys/kernel/debug/extfrag/extfrag_index。現時点では、これ以上の性能を発揮できるほど新しいカーネルを搭載したボックスを所有していません。

あるいは、何らかの cron ジョブ (これは非常に醜い) を実行して、に書き込むことで手動でメモリを圧縮することもできます/proc/sys/vm/compact_memory。

しかし、正直に言うと、この問題を回避するためにシステムを調整する方法は実際にはないと思います。これはメモリアロケータがこのように動作することの性質によるものです。使用しているプラットフォームのアーキテクチャを変更することが、おそらく唯一の根本的な解決方法です。

Question 2

始めに：あなたはすべきです本当に64 ビットオペレーティングシステムを選択してください。ここで 32 ビットのままにする正当な理由はありますか?

システムをもっと詳しく調べなければ、できれば障害が発生したときの状況を調べなければ、この問題を診断するのは難しいため、私の (簡単な) 投稿は、多かれ少なかれ一般的な 32 ビットシステムのメモリ問題を対象としています。64 ビットにすると、この問題はすべて解消されると言いましたか?

あなたの問題は3つあります。

まず、PAE カーネルでも、プロセスごとのアドレス空間は 4GiB[1] に制限されています。つまり、squid インスタンスはプロセスごとに 4GiB を超える RAM を消費することはできません。私は squid にそれほど詳しくありませんが、これがメインのプロキシサーバーである場合、いずれにしても十分ではない可能性があります。

2 番目に、膨大な量の RAM を搭載した 32 ビットシステムでは、ZONE_NORMAL と呼ばれるメモリの大部分が、ZONE_HIGHMEM のメモリを使用するために必要なデータ構造を格納するために使用されます。これらのデータ構造自体は ZONE_HIGHMEM に移動できません。カーネルが自身の目的で使用するメモリは常に ZONE_NORMAL (つまり最初の 1GiB 程度) にある必要があるためです。ZONE_HIGHMEM のメモリが多ければ多いほど (この場合は多ければ多いほど)、この問題は大きくなります。カーネルは ZONE_HIGHMEM を管理するために ZONE_NORMAL からさらに多くのメモリを必要とするためです。ZONE_NORMAL の空きメモリがなくなると、システムが一部のタスクで失敗する可能性があります。ZONE_NORMAL は、多く32 ビットシステムではさまざまなことが起こります。たとえば、カーネル関連のメモリ操作などです。

3 番目に、ZONE_NORMAL にいくらかのメモリが残っていたとしても (ログを詳しく調べていません)、一部のメモリ操作では断片化されていないメモリが必要になります。たとえば、すべてのメモリが非常に小さな断片に断片化されている場合、それ以上のメモリを必要とする操作は失敗します。[3] ログをざっと見ると、ZONE_DMA と ZONE_NORMAL にかなりの量の断片化があることがわかります。

編集: 上記の Mlfe の回答には、これがどのように詳細に機能するかについての優れた説明があります。

繰り返しますが、64 ビットシステムでは、すべてのメモリは ZONE_NORMAL にあります。64 ビットシステムには HIGHMEM ゾーンはありません。問題は解決しました。

編集: ここ [4] を見て、oom-killer に重要なプロセスをそのままにしておくように指示できるかどうかを確認してください。これですべてが解決するわけではありませんが (解決するかどうかはわかりませんが)、試してみる価値はあるかもしれません。

[1]http://en.wikipedia.org/wiki/Physical_address_extension#デザイン

[2]http://www.redhat.com/archives/rhelv5-list/2008-9月/msg00237.htmlそしてhttps://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Tuning_and_Optimizing_Red_Hat_Enterprise_Linux_for_Oracle_9i_and_10g_Databases/sect-Oracle_9i_and_10g_Tuning_Guide-Hardware_Architectures_and_Linux_Kernels-a32_bit_Architecture_and_the_hugemem_Kernel.html

[3]http://bl0rg.krunch.be/oom-frag.html

[4]http://lwn.net/Articles/317814/

Answer

始めに：あなたはすべきです本当に64 ビットオペレーティングシステムを選択してください。ここで 32 ビットのままにする正当な理由はありますか?

システムをもっと詳しく調べなければ、できれば障害が発生したときの状況を調べなければ、この問題を診断するのは難しいため、私の (簡単な) 投稿は、多かれ少なかれ一般的な 32 ビットシステムのメモリ問題を対象としています。64 ビットにすると、この問題はすべて解消されると言いましたか?

あなたの問題は3つあります。

まず、PAE カーネルでも、プロセスごとのアドレス空間は 4GiB[1] に制限されています。つまり、squid インスタンスはプロセスごとに 4GiB を超える RAM を消費することはできません。私は squid にそれほど詳しくありませんが、これがメインのプロキシサーバーである場合、いずれにしても十分ではない可能性があります。

2 番目に、膨大な量の RAM を搭載した 32 ビットシステムでは、ZONE_NORMAL と呼ばれるメモリの大部分が、ZONE_HIGHMEM のメモリを使用するために必要なデータ構造を格納するために使用されます。これらのデータ構造自体は ZONE_HIGHMEM に移動できません。カーネルが自身の目的で使用するメモリは常に ZONE_NORMAL (つまり最初の 1GiB 程度) にある必要があるためです。ZONE_HIGHMEM のメモリが多ければ多いほど (この場合は多ければ多いほど)、この問題は大きくなります。カーネルは ZONE_HIGHMEM を管理するために ZONE_NORMAL からさらに多くのメモリを必要とするためです。ZONE_NORMAL の空きメモリがなくなると、システムが一部のタスクで失敗する可能性があります。ZONE_NORMAL は、多く32 ビットシステムではさまざまなことが起こります。たとえば、カーネル関連のメモリ操作などです。

3 番目に、ZONE_NORMAL にいくらかのメモリが残っていたとしても (ログを詳しく調べていません)、一部のメモリ操作では断片化されていないメモリが必要になります。たとえば、すべてのメモリが非常に小さな断片に断片化されている場合、それ以上のメモリを必要とする操作は失敗します。[3] ログをざっと見ると、ZONE_DMA と ZONE_NORMAL にかなりの量の断片化があることがわかります。

編集: 上記の Mlfe の回答には、これがどのように詳細に機能するかについての優れた説明があります。

繰り返しますが、64 ビットシステムでは、すべてのメモリは ZONE_NORMAL にあります。64 ビットシステムには HIGHMEM ゾーンはありません。問題は解決しました。

編集: ここ [4] を見て、oom-killer に重要なプロセスをそのままにしておくように指示できるかどうかを確認してください。これですべてが解決するわけではありませんが (解決するかどうかはわかりませんが)、試してみる価値はあるかもしれません。

[1]http://en.wikipedia.org/wiki/Physical_address_extension#デザイン

[2]http://www.redhat.com/archives/rhelv5-list/2008-9月/msg00237.htmlそしてhttps://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Tuning_and_Optimizing_Red_Hat_Enterprise_Linux_for_Oracle_9i_and_10g_Databases/sect-Oracle_9i_and_10g_Tuning_Guide-Hardware_Architectures_and_Linux_Kernels-a32_bit_Architecture_and_the_hugemem_Kernel.html

[3]http://bl0rg.krunch.be/oom-frag.html

[4]http://lwn.net/Articles/317814/

Question 3

@MIfeはすでに提供しているカーネル内のメモリ割り当てがどのように処理されるかについての優れた記述また、64 ビット OS への切り替えや、を介した手動メモリ圧縮などの厄介なハックなどの適切なソリューションも提供されまし/proc/sys/vm/compact_memoryたcron。

私の2セントは、あなたを助けるかもしれない別の回避策です:カーネルバックトレースに次の
ものがあることに気づいたので、次のようにします:tcp_tso_segment

# ethtool -K ethX tso off gso off lro off

mmより低い順序の使用を強制することで、圧力を軽減できます。

追伸すべてのオフロードのリストは以下から取得できます。# ethtool -k ethX

Answer

@MIfeはすでに提供しているカーネル内のメモリ割り当てがどのように処理されるかについての優れた記述また、64 ビット OS への切り替えや、を介した手動メモリ圧縮などの厄介なハックなどの適切なソリューションも提供されまし/proc/sys/vm/compact_memoryたcron。

私の2セントは、あなたを助けるかもしれない別の回避策です:カーネルバックトレースに次の
ものがあることに気づいたので、次のようにします:tcp_tso_segment

# ethtool -K ethX tso off gso off lro off

mmより低い順序の使用を強制することで、圧力を軽減できます。

追伸すべてのオフロードのリストは以下から取得できます。# ethtool -k ethX

Question 4

パニックは、sysctl の「vm.panic_on_oom = 1」が設定されているために発生します。これは、システムを再起動すると正常な状態に戻るという考え方です。これは sysctl.conf で変更できます。

一番上に、squid が oom killer を呼び出しましたと書かれています。squid の設定と最大メモリ使用量を確認してください (または、64 ビット OS に移行してください)。

/proc/meminfo には、使用中のメモリゾーンが多数表示されています。つまり、36 GB のメモリを搭載した 32 ビットカーネルが動作していることになります。また、通常ゾーンでは、Squid のメモリ要求を満たすために、カーネルが 982 ページをスキャンしましたが、成功しなかったことがわかります。

pages_scanned:982 all_unreclaimable? yes

Answer

パニックは、sysctl の「vm.panic_on_oom = 1」が設定されているために発生します。これは、システムを再起動すると正常な状態に戻るという考え方です。これは sysctl.conf で変更できます。

一番上に、squid が oom killer を呼び出しましたと書かれています。squid の設定と最大メモリ使用量を確認してください (または、64 ビット OS に移行してください)。

/proc/meminfo には、使用中のメモリゾーンが多数表示されています。つまり、36 GB のメモリを搭載した 32 ビットカーネルが動作していることになります。また、通常ゾーンでは、Squid のメモリ要求を満たすために、カーネルが 982 ページをスキャンしましたが、成功しなかったことがわかります。

pages_scanned:982 all_unreclaimable? yes

Linux の oom 状況 (32 ビットカーネル)

答え1

リクエストの注文サイズとカーネルが特定の注文サイズをどのように処理するか

選択されているゾーン。

このゾーンが使用する透かし。

ゾーン内の断片化。

OOM-killer が呼び出されましたか? なぜですか?

修正

答え2

答え3

答え4

関連情報