Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
恐怖のOOM killerを召喚
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
Satoru Takeuchi
PRO
September 24, 2022
Technology
300
0
Share
恐怖のOOM killerを召喚
以下動画のテキストです
https://youtu.be/o7SbjLpm5-c
Satoru Takeuchi
PRO
September 24, 2022
More Decks by Satoru Takeuchi
See All by Satoru Takeuchi
システム強制終了時にファイルシステムの整合性を保つ~ コピーオンライト編 ~
sat
PRO
0
48
システム強制終了時に ファイルシステムの整合性を保つ ~ ジャーナリング編 ~
sat
PRO
1
51
ファイルシステムの整合性を回復するfsck
sat
PRO
1
53
小学校5,6年生向けキャリア教育 大人になるまでの道
sat
PRO
8
4.2k
ファイルシステムの不整合
sat
PRO
2
150
書籍執筆での生成AIの活用
sat
PRO
2
490
ChatGPTに従って体調管理2026
sat
PRO
0
180
eBPF
sat
PRO
1
150
waruiBPF
sat
PRO
0
140
Other Decks in Technology
See All in Technology
TypeScriptエンジニアのためのWASMランタイム入門:AssemblyScriptから理解するメモリの実態(ayano)
ayanoyuki
0
130
AI時代に改めて考える、ドメイン駆動設計 - モデリングが「AIへの共通言語」になる
littlehands
7
2.3k
イベントで大活躍する電子ペーパー名札 〜その3〜 / ビジュアルプログラミングIoTLT vol.23
you
PRO
0
130
コーディングエージェントはTypeScriptの 型エラーをどう自己修正しているのか
melonps
4
480
既存プロダクトQAから新規プロダクトQAへ
ryotakahashi
0
200
サプライチェーン攻撃への備えについて考えている #湘なんか
stefafafan
3
2.4k
Amazon CloudFrontにおけるAIボットアクセス制御のポイント
kizawa2020
4
270
論文紹介:Pixal3D (SIGGRAPH 2026)
tenten0727
0
720
老舗OCIクラウドインテグレーターが語る-現場で培ったクラウドリフトのリアルと成功のカギ
shinpy
0
120
類似画像検索モデルの開発ノウハウ
lycorptech_jp
PRO
3
800
Loadbalancing exporter internals
ymotongpoo
1
130
TSKaigi 2026 - Auth.jsからBetter Authへの 移行に見る「型とランタイム」の 設計思想の変化
teamlab
PRO
1
260
Featured
See All Featured
Introduction to Domain-Driven Design and Collaborative software design
baasie
1
790
First, design no harm
axbom
PRO
2
1.2k
Imperfection Machines: The Place of Print at Facebook
scottboms
270
14k
[RailsConf 2023] Rails as a piece of cake
palkan
59
6.6k
HTML-Aware ERB: The Path to Reactive Rendering @ RubyCon 2026, Rimini, Italy
marcoroth
1
94
Skip the Path - Find Your Career Trail
mkilby
1
130
Bootstrapping a Software Product
garrettdimon
PRO
307
120k
Paper Plane
katiecoart
PRO
1
50k
How STYLIGHT went responsive
nonsquared
100
6.1k
SEOcharity - Dark patterns in SEO and UX: How to avoid them and build a more ethical web
sarafernandez
0
190
Sam Torres - BigQuery for SEOs
techseoconnect
PRO
0
270
Building Flexible Design Systems
yeseniaperezcruz
330
40k
Transcript
恐怖のOOM killerを召喚 Sep. 22nd, 2022 Satoru Takeuchi twitter: satoru_takeuchi
やること • 前回の動画「プロセスを殺戮する恐怖のOOM killer」で紹介したOOM killerを実際 に召喚してプロセスを殺していただく • 発動したことをどうやって検出するかの確認
やってみる • 前準備 ◦ 以下コマンドの実行によって swap機能を切る ▪ sudo swapoff -a
▪ swap機能については別動画で今後説明予定 • やること ◦ 8GiB搭載のシステムで8GiBのメモリを使うプログラムを実行 ◦ 📝 メモリは獲得後に最初に書き込むまで使用していないとみなされる ▪ この機能をdemand pagingと呼ぶ(別動画で紹介予定)
うまくいった…のか? • プロセスは大量にログを出して死んだ • 実はこれはOut Of Memoryとは異なる ◦ Out Of
Memory: メモリを使い切ってしまった状態 ◦ メモリ獲得処理の失敗 : プロセスに要求されたメモリを獲得させるとシステムのメモリを使いつくして しまうと判断した場合、獲得そのものを失敗させる • メモリ獲得直後にデバッグメッセージを入れればわかる
ではどうすれば? • いろいろ方法はあるが、一番楽なのはメモリ獲得を失敗させなくすること • sysctlのvm.overcommit_memoryパラメタが使える ◦ 値が1だと(デフォルトは0)メモリ獲得時に空きメモリ量を考慮しない • 以下コマンド実行後に再びメモリを大量に獲得するプロセス実行 ◦
sudo sysctl vm.overcommit_memory=1
今度は死んだ…ように見えるが、地味でよくわからない • OOMが起きたかどうかはdmesgコマンドでカーネルログを見ればわかる ◦ sudo dmesg
まとめ • OOMは起きると悲しいが、意図的に召喚するのはちょっと面倒 • 「これはOOM killerにやられたか」と思ったらdmesgを見るとよい • dmesgを見ると、以下のようなことがわかる ◦ OOMになったかどうか、OOM
killerが発動したかどうか ◦ OOM発生時、どのようなプロセスが存在していたか ◦ どのプロセスが殺されたか