タグ付けされた質問 「oom」

server_Aに単一の50 GBファイルがあり、それをserver_Bにコピーしています。走る server_A$ rsync --partial --progress --inplace --append-verify 50GB_file root@server_B:50GB_file Server_Bには32 GBのRAMと2 GBのスワップがあります。ほとんどはアイドル状態であり、多くの空きRAMが必要でした。十分なディスク容量があります。約32 GBで、リモート側が接続を閉じたため、転送は中止されます。 Server_Bがネットワークから削除されました。データセンターに再起動を依頼します。クラッシュする前のカーネルログを見ると、0バイトのスワップを使用しており、プロセスリストはごくわずかなメモリを使用していました（rsyncプロセスは600 KBのRAMを使用していると表示されていました）が、oom_killerはワイルドになり、ログの最後の部分は、metalogのカーネルリーダープロセスを強制終了する場所です。 これはカーネル3.2.59、32ビットです（したがって、いずれのプロセスも4 GBを超えるマップはできません）。 まるでLinuxが寿命の長い実行中のデーモンよりもキャッシュを優先しているかのようです。何が？そして、どうすれば再び起こるのを止めることができますか？ oom_killerの出力は次のとおりです。 Sep 23 02:04:16 [kernel] [1772321.850644] clamd invoked oom-killer: gfp_mask=0x84d0, order=0, oom_adj=0, oom_score_adj=0 Sep 23 02:04:16 [kernel] [1772321.850649] Pid: 21832, comm: clamd Tainted: G C 3.2.59 #21 Sep 23 02:04:16 [kernel] …

66 rsync  oom  oom-killer 

LinuxのOOMキラーは、さまざまなアプリケーションで大混乱を引き起こしますが、これを改善するためにカーネル開発側で実際に行われていることはあまりないようです。新しいサーバーをセットアップする際のベストプラクティスとして、メモリのオーバーコミットのデフォルトを元に戻す、つまりvm.overcommit_memory=2、特定の用途でオンにする必要があることがわかっていない限り、オフ（）にすると良いでしょうか？そして、これらのユースケースは、オーバーコミットをしたいことがわかっている場合はどうなりますか？ ボーナスとして、この場合の動作はスワップスペースにvm.overcommit_memory=2依存するvm.overcommit_ratioため、この2つのセットアップ全体が合理的に機能し続けるように、後の2つのサイズを決定するための良い経験則は何でしょうか？

37 linux  memory  kernel  oom 

物理メモリが少ないがスワップスペースが十分にあるときに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: …

28 linux  swap  oom 

今日、（偶然に）Linuxボックスで、すぐに大量のメモリを使用するプログラムを実行しました。私のシステムがフリーズし、応答しなくなり、犯罪者を殺すことができませんでした。 今後これを防ぐにはどうすればよいですか？少なくともレスポンシブコアまたは何かを実行し続けることはできませんか？

25 linux  oom 

継続的なoom＆panicの状況は未解決です。システムがすべてのRAM（36GB）を使い果たすかどうかわかりません。このシステムがなぜこのような状況を引き起こしたのですか？32ビットLinuxシステムのlowmemゾーンに関連していると思われます。カーネルパニックとoom-killerからのログを分析するにはどうすればよいですか？ 宜しくお願いします、 カーネル3.10.24 Dec 27 09:19:05 2013 kernel: : [277622.359064] squid invoked oom-killer: gfp_mask=0x42d0, order=3, oom_score_adj=0 Dec 27 09:19:05 2013 kernel: : [277622.359069] squid cpuset=/ mems_allowed=0 Dec 27 09:19:05 2013 kernel: : [277622.359074] CPU: 9 PID: 15533 Comm: squid Not tainted 3.10.24-1.lsg #1 Dec 27 09:19:05 2013 kernel: : [277622.359076] …

15 linux  kernel-panic  oom  oom-killer 

Googleを見て、スコアのproc/<pid>/oom_score計算方法を説明するものが見つかりませんでした。使用される合計メモリを使用するのではなく、このスコアを使用するのはなぜですか？

12 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 …

12 postgresql  oom 

問題 複数の「メモリ不足」メッセージの後にサーバーがクラッシュし、原因を特定しようとしています。ユーザーランドにある場合-どのプロセス。カーネル内にある場合-どのカーネルモジュール。 詳細 クラッシュユーティリティを使用して、サーバーでOOMをトリガーした原因を調査する方法を見つけようとしています。 新しいサーバーペアのインストールの一環として、14TB DRBDデバイスの初期化を開始しました。その頃、DRBDシンカーレート構成で遊んでいるときに、結合されたネットワークインターフェイスの一部を上下させたときに、サーバーの1つがクラッシュしました。30秒間で39のOut of memory: Kill process ####メッセージが生成されました。その後、次のようにクラッシュしました： Kernel panic - not syncing: Out of memory and no killable processes... システムクラッシュによりkdumpがトリガーされました。これでvmcore.flat、問題を調査するのに簡単に使用できる素敵なファイルができましたが、すべてのメモリがどこに行ったのかを見つけるのに苦労しています。 私が知っている唯一のリソースはDedoimedoのサイトで、これには素晴らしい説明があり、Kernel Crash Bookがあります。これらは回答で提案されている唯一のリソースでもあるためcrash、調査する唯一の方法であると思います。 インシデントで事後分析を行う別の方法があれば、喜んで受け入れます。それはcrash私が知っている唯一のユーティリティです。私が今持っているのはvmcore.flatファイルだけです、そして、私が知る必要があるのは、どのコンポーネントがそのメモリをすべて使い果たしたかです。カーネルモジュールの問題、より具体的にはボンディングモジュール（インターフェイスをダウンさせるとトリガーされる）、DRBDモジュール（CentOS 6.3のツリーからビルドされたバージョン8.3.15）、または10Gイーサネットモジュール（mlnx_en停止したインターフェイスであるツリー、またはbnx2xアクティブのままであったインターフェイスであるツリーから構築されます）。私が知る必要があるのは、疑念を検証する方法があるかどうかだけです。 これまでのところ、クラッシュユーティリティを使用して次の情報を抽出することができました。 使用メモリ量を確認しました $ crash /usr/lib/debug/lib/modules/2.6.32-279.5.2.el6.x86_64/vmlinux vmcore.flat .... crash> kmem -i PAGES TOTAL PERCENTAGE TOTAL MEM 16482587 62.9 GB ---- FREE 54610 …

12 centos6  troubleshooting  server-crashes  memory-leak  oom 

コアダンプを取得する方法、またはoom-killerによって強制終了されたプロセスをデバッグできる方法はありますか？ または、代わりにABRTを使用してプロセスを強制終了するようにoom-killerを設定しますか？

10 oom  dump 

EDIT2：この問題は3.8.0-25-generic＃37-Ubuntu SMPにも存在するようです 編集：「なぜddを使用してファイルに書き込むことによってLinuxのメモリ不足マネージャーがトリガーされるのですか？」という元のタイトルからの質問を変更しました。以下で説明する一般的な問題について心配していることをよりよく反映するために： メモリ制限（300MBに設定）を超えるサイズのファイルを書き込むと、LXCコンテナーでOOMキラーがプロセスを強制終了するという厄介なシナリオに遭遇しています。実際には512 MBのRAMしかないXen仮想マシン（EC2 t1.micro）でアプリケーションを実行しても問題は発生しないため、コンテナーのメモリ制限に関するファイルバッファリングに問題があるようです。 簡単な例として、ddによって書き込まれた大きなファイルがどのように問題を引き起こすかを示します。繰り返しますが、この問題はすべてのアプリケーションを悩ませています。アプリケーションのキャッシュが大きくなりすぎるという一般的な問題を解決しようとしています。「dd」を機能させる方法を理解しています。 シナリオ： LXCコンテナーで、memory.limit_in_bytesが300 MBに設定されています。 私は次のように500 MB以下のファイルをddしようとします。 dd if=/dev/zero of=test2 bs=100k count=5010 ほぼ20％の時間、Linux OOMマネージャーはこのコマンドによってトリガーされ、プロセスが強制終了されます。言うまでもなく、これは非常に意図しない動作です。ddは、コンテナ内で実行されるプログラムによる実際の「有用な」ファイル書き込みをシミュレートすることを目的としています。 詳細：ファイルキャッシュが大きくなる（260 MB）一方で、rssとファイルマップはかなり低いままのようです。以下は、書き込み中にmemory.statがどのように見えるかの例です。 cache 278667264 rss 20971520 mapped_file 24576 pgpgin 138147 pgpgout 64993 swap 0 pgfault 55054 pgmajfault 2 inactive_anon 10637312 active_anon 10342400 inactive_file 278339584 active_file 319488 unevictable 0 hierarchical_memory_limit 300003328 hierarchical_memsw_limit …

10 linux  ubuntu  lxc  oom  cgroup 

私のシステムに十分な空きRAMがあっても、OOMキラーは物事を殺しているようです： （フル解像度） （フル解像度） 27分と408プロセス後、システムは再び応答を開始しました。約1時間後に再起動しましたが、その後すぐにメモリ使用率は通常に戻りました（このマシンの場合）。 検査すると、ボックスでいくつかの興味深いプロセスが実行されています。 USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND [...snip...] root 1399 60702042 0.2 482288 1868 ? Sl Feb21 21114574:24 /sbin/rsyslogd -i /var/run/syslogd.pid -c 4 [...snip...] mysql 2022 60730428 5.1 1606028 38760 ? Sl Feb21 21096396:49 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock …

10 linux  centos6  linode  oom 

十分なRAMと十分な量のSWAPが同時に利用可能であるにもかかわらず、Linux OOMキラーによって2つのプロセスが強制終了された理由を調査しています。 この回答でそれを解釈すると、最初のメモリ要求は2 ^ 2 = 4ページ（16KB）のメモリ（注文フラグ）を要求し、「通常」ゾーンからのものであることを望みました。 Jan 27 04:26:14 kernel: [639964.652706] java invoked oom-killer: gfp_mask=0x26000c0, order=2, oom_score_adj=0 そして、出力を正しく解析すると、十分なスペースがあります。 Node 0 Normal free:178144kB min:55068kB low:68832kB high:82600kB 2回目は数分後に同じ要求があり、十分なスペースも利用できるようです。 なぜOOMキラーがトリガーされたのですか？情報を間違って解析していますか？ システムは、4.4.0-59 x64カーネルを搭載した14.04 Ubuntuです。 vm.overcommit_memory設定は「0」（に設定されているヒューリスティック最適ではないかもしれません）。 インスタンス1： Jan 27 04:26:14 kernel: [639964.652706] java invoked oom-killer: gfp_mask=0x26000c0, order=2, oom_score_adj=0 Jan 27 04:26:14 kernel: [639964.652711] java …

9 linux  oom 

約18時間実行した後、このシステムは約10 GBのメモリを使用しているため、通常のタスクを実行するとOOMキラーがトリガーされます。 # free -h total used free shared buffers cached Mem: 14G 9.4G 5.3G 400K 27M 59M -/+ buffers/cache: 9.3G 5.4G Swap: 0B 0B 0B # cat /proc/meminfo MemTotal: 15400928 kB MemFree: 5567028 kB Buffers: 28464 kB Cached: 60816 kB SwapCached: 0 kB Active: 321464 kB Inactive: 59156 kB …

9 linux  ubuntu  memory-usage  memory-leak  oom 

OutOfMemoryErrorsによってトリガーされた適切なヒープダンプを取得しようとすると、私のチームは困難に直面しています。特定の理由により、現在、HeapDumpOnOutOfMemoryErrorフラグを使用する代わりに、bashスクリプトから呼び出されたjmapでダンプを取得しています。ヒープサイズが約3 GBの64ビット1.6 JVMを使用しています。ヒープダンプは、90％の確率で失敗します（推定）。 メモリの問題のトラブルシューティングに使用できるクリーンなヒープダンプを取得する確率を向上させるためにできることはありますか？私は、jmapがJava 1.4で大きな問題を抱えていたことを読みましたが、それらの問題の大部分は今対処する必要があります。

9 java  oom  outofmemoryerror  dump