Ubuntu 14.04でOOM killer
を無効にするにはどうすればよいですか?説明があります ここ ですが、OPでは機能していないようです。明確なステップで答えを得るのは素晴らしいことです。
これはXYの問題です。つまり、あなたはそれを知っているかどうかにかかわらず、問題(X)を持っており、問題Yである異なる問題を解くことによって物事を解決できると信じています。
なぜoomkillerを無効にしたいのですか?それがあなたが解決する必要のあるXの問題です。あなたがすべきことは、問題Xを調査し、詳細に説明することです。その詳細を提供してください。私たちがお手伝いできる可能性があります。
問題Yを追いかけ、oomkillerを無効にすることは、一般的に非常に悪い考えこれは確かにそれがするよりもはるかに大きな問題を引き起こすでしょう 解決する。
Oomkillerを呼び出すことは、物事が記憶的にうまくいかず、Doomが差し迫っているときに、絶望的な最後の手段です。システムには6人の乗客がいて、残り1時間で、酸素供給はわずか5工数です。 1人の乗客をランダムに殺す(ランダムではない- 実際には代謝が高い人 )ことはひどいことだと思うかもしれませんが、代わりに6人の乗客全員を10分前に窒息死させることですドッキング。
Oomkillerを無効にすることに成功しました。システムが再起動し、順調に進みます。今、2つのことが起こる可能性があります:
しかし、なぜoomkillerが必要だったのでしょうか。これは、一部のプロセスがメモリを必要とし、システムがそのメモリを提供できないことを発見したためです。
私たちが「memoryhog」と呼ぶプロセスがありますが、これはoomkillerによって殺されたはずですが、今ではこれは起こりません。 何が起こりますか?
起動時にこれらのコマンドを発行しました
sysctl vm.panic_on_oom=1
sysctl kernel.panic=5
またはこれを/etc/sysctl.conf
に追加して、再起動しました
vm.panic_on_oom=1
kernel.panic=5
システムが停止するとすぐにパニックになり、5秒後に再起動します。
起動時に、一部のプロセスを「消耗品」として分類し、その他のプロセスを「消耗品ではない」として分類します。たとえば、Apacheは消耗品であり、MySQLではありません。したがって、Apacheが非常に大きな要求に遭遇した場合(LAMPシステムでは、通常、メモリバウンドまたはリークアプローチを変更する代わりに、PHPメモリ割り当てをばかげて大きな値に設定する「簡単な修正」から発生します) 、MySQLがより大きな豚であっても、Apacheの子は殺されます。このようにすると、顧客は空白のページを表示し、RELOADを押して、別のページを取得し、最後にやめます。
これを行うには、起動時にMySQLのPIDを記録し、そのOOMレーティングを調整します。
echo -15 > /proc/$( pidof mysql )/oom_adj
ただし、この状況では、 Apacheの子conf も調整します。
このオプションで問題が解決した場合は、otherプロセスに問題があることを意味します(たとえば、大きすぎるPHPプロセス。これは、最適ではないアルゴリズムまたはデータ選択段階。実際に解決すべき問題が1つになるまで、チェーンをたどります。
おそらく、さらにRAMをインストールしても同じ効果があります。
このオプションでは、MySQL自体が大きくなりすぎると(たとえば、innodb_pool_size値を失敗した場合)、MySQLはとにかく強制終了されます。
上記と同じですが、調整は-17に設定されています。
私は今MySQLについて話しているが、ほとんどのプログラムは同じように動作するだろう。私はPostgreSQLとOracleの両方がそうすることを確かに知っています(そして彼らは権利があります。あなたは危険にさらされてRDBMSを悪用します)。
このオプションは、oomkillerが殺すという点で危険です他の誰か、おそらく繰り返し、しかし何よりもおそらく$ MYPRECIOUSSS自体のため。
したがって、暴走したプロセスは、システムが使用できなくなり、ログインしてチェックしたり何かをしたりすることさえできなくなるまで、メモリから他のすべての人を追い出します。その後すぐに、MySQLは自身のステータス情報を破壊し、恐ろしくクラッシュします。長いfsck
セッション、骨の折れるテーブル修復、慎重なトランザクションの再構築が続きます。
私自身の経験から、経営陣は、事実上、時限爆弾を仕掛けた経営陣に非常に不幸になると言うことができます。多くの非難が飛び交うでしょう(MySQLの設定が間違っていた、Apacheがリークしていた、OOMKillerがクレイジーだった、ハッカーだった...)ので、「1つ」は「多数」かもしれません。ただし、この3番目のオプションでは、完全で適切な、常に更新および監視されるバックアップwithリカバリテストの必要性を十分に強調することはできません。
このオプションは joke のように見えるかもしれません。古いWindowsのようにXP「ブルースクリーンを永遠に回避する方法!」へのトリック-これは実際に実際に機能しました...-を設定することによって ほとんど知られていない変数 それは彼らをマゼンタに変えました。
ただし、/etc/sysctl.conf
ファイルを編集して次の行を追加することにより、oomkillerが呼び出されないようにすることができます。
vm.overcommit_memory = 2
vm.overcommit_kbytes = 0
次に、コマンドsysctl vm.overcommit_memory=2
およびsysctl vm.overcommit_kbytes=0
も実行して、再起動の必要性を回避します。
今、何が起きた?システムに十分なメモリがある場合は、何もしなかったかのように何も起こりません。
システムのメモリが不足すると、newプロセスを開始できないか、開始時にクラッシュします。彼らは記憶を必要とします、そして、記憶はそこにありません。したがって、それらは「oomkilled」ではなく、「メモリ不足エラーによって強制終了」されます。結果はまったく同じであり、それが一部の人がこれを冗談だと思う理由です。
システムのメモリが不足している理由を調査します。これは、本質的に避けられない、修復可能、または完全に回避できる可能性があります。本質的に避けられない場合は、問題をより高くし、より多くのメモリをインストールする必要があります。
バグや入力の誤り、またはクリティカルになる前に認識できる状態が原因でプロセスが暴走したことが原因である場合は、修復可能です。プロセスを再設計し、そのためのケースを構築する必要があります。
また、異なるサーバー間でサービスを分割するか、1つ以上のプロセスをより注意深く調整するか、(再び)障害のあるプロセスを再設計することで、問題を完全に回避できる場合もあります。
いくつかのシナリオでは、より効率的な解決策は「それにいくらかのお金を投げる」かもしれません-256GB RAM)のサーバーで問題が発生し、最大で280が必要であることがわかっている場合近い将来、320GBへのアップグレードは、すべて込みで3,000米ドル程度の費用がかかり、週末に行われる可能性があります。これは、1日あたり150,000米ドルのダウンタイム費用、またはそれぞれ14,000米ドルで4回のプログラミングマン月と比較して、 andは、日常の状況でもパフォーマンスを向上させる可能性があります。
別の方法として、非常に大きなスワップ領域を設定し、オンデマンドでアクティブ化することもできます。 /var/tmp
に32GBの空き容量があるとすると(メモリにバックアップされていない場合):
dd if=/dev/zero of=/var/tmp/oomswap bs=1M count=32768
# or: fallocate -l 32g /var/tmp/oomswap
chmod 600 /var/tmp/oomswap
mkswap /var/tmp/oomswap
swapon /var/tmp/oomswap
これにより、さまざまなプロセスに息を吹き込むのに役立つ32Gbファイルが作成されます。また、swappinessを調べて、場合によっては増やすこともできます。
cat /proc/sys/vm/swappiness
Ubuntu 14.04のデフォルトのswappinessは60で、ほとんどのユーザーにとって問題ありません。
sysctl vm.swappiness=70
echo 2 > /proc/sys/vm/overcommit_memory echo 0 > /proc/sys/vm/overcommit_kbytes
オプションの説明については、 https://www.kernel.org/doc/Documentation/sysctl/vm.txt を参照してください。
標準の警告が適用されます。システムのメモリが不足していて、プログラムがそれ以上を要求すると、システムは拒否されます。これは、多くのプログラムがクラッシュまたはウェッジするポイントです。