$30 off During Our Annual Pro Sale. View Details »

恐怖のOOM killerを召喚

恐怖のOOM killerを召喚

以下動画のテキストです
https://youtu.be/o7SbjLpm5-c

Satoru Takeuchi
PRO

September 24, 2022
Tweet

More Decks by Satoru Takeuchi

Other Decks in Technology

Transcript

  1. 恐怖のOOM killerを召喚 Sep. 22nd, 2022 Satoru Takeuchi twitter: satoru_takeuchi

  2. やること • 前回の動画「プロセスを殺戮する恐怖のOOM killer」で紹介したOOM killerを実際 に召喚してプロセスを殺していただく • 発動したことをどうやって検出するかの確認

  3. やってみる • 前準備 ◦ 以下コマンドの実行によって swap機能を切る ▪ sudo swapoff -a

    ▪ swap機能については別動画で今後説明予定 • やること ◦ 8GiB搭載のシステムで8GiBのメモリを使うプログラムを実行 ◦ 📝 メモリは獲得後に最初に書き込むまで使用していないとみなされる ▪ この機能をdemand pagingと呼ぶ(別動画で紹介予定)
  4. うまくいった…のか? • プロセスは大量にログを出して死んだ • 実はこれはOut Of Memoryとは異なる ◦ Out Of

    Memory: メモリを使い切ってしまった状態 ◦ メモリ獲得処理の失敗 : プロセスに要求されたメモリを獲得させるとシステムのメモリを使いつくして しまうと判断した場合、獲得そのものを失敗させる • メモリ獲得直後にデバッグメッセージを入れればわかる
  5. ではどうすれば? • いろいろ方法はあるが、一番楽なのはメモリ獲得を失敗させなくすること • sysctlのvm.overcommit_memoryパラメタが使える ◦ 値が1だと(デフォルトは0)メモリ獲得時に空きメモリ量を考慮しない • 以下コマンド実行後に再びメモリを大量に獲得するプロセス実行 ◦

    sudo sysctl vm.overcommit_memory=1
  6. 今度は死んだ…ように見えるが、地味でよくわからない • OOMが起きたかどうかはdmesgコマンドでカーネルログを見ればわかる ◦ sudo dmesg

  7. まとめ • OOMは起きると悲しいが、意図的に召喚するのはちょっと面倒 • 「これはOOM killerにやられたか」と思ったらdmesgを見るとよい • dmesgを見ると、以下のようなことがわかる ◦ OOMになったかどうか、OOM

    killerが発動したかどうか ◦ OOM発生時、どのようなプロセスが存在していたか ◦ どのプロセスが殺されたか