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
Satoru Takeuchi
PRO
September 24, 2022
Technology
0
200
恐怖のOOM killerを召喚
以下動画のテキストです
https://youtu.be/o7SbjLpm5-c
Satoru Takeuchi
PRO
September 24, 2022
Tweet
Share
More Decks by Satoru Takeuchi
See All by Satoru Takeuchi
Linuxのブートプロセス
sat
PRO
5
63
シェルのジョブ
sat
PRO
1
20
常駐サービスを実現するデーモンプロセス
sat
PRO
0
24
絶対殺すSIGKILLシグナルと絶対死なないプロセス
sat
PRO
3
81
シェルのセッション
sat
PRO
2
31
RubyでKubernetesプログラミング
sat
PRO
4
180
プロセスの生成 exec編
sat
PRO
1
41
プロセスの生成 fork&exec編
sat
PRO
0
36
プロセスの生成 コピーオンライトを使ったfork編
sat
PRO
0
35
Other Decks in Technology
See All in Technology
LINE NEWSにおけるバックエンド開発
lycorptech_jp
PRO
0
250
役員・マネージャー・著者・エンジニアそれぞれの立場から見たAWS認定資格
nrinetcom
PRO
4
6.1k
OPENLOGI Company Profile
hr01
0
60k
設計を積み重ねてシステムを刷新する
sansantech
PRO
0
170
急成長する企業で作った、エンジニアが輝ける制度/ 20250227 Rinto Ikenoue
shift_evolve
0
140
わたしがEMとして入社した「最初の100日」の過ごし方 / EMConfJp2025
daiksy
14
5.1k
"TEAM"を導入したら最高のエンジニア"Team"を実現できた / Deploying "TEAM" and Building the Best Engineering "Team"
yuj1osm
1
190
1行のコードから社会課題の解決へ: EMの探究、事業・技術・組織を紡ぐ実践知 / EM Conf 2025
9ma3r
11
3.9k
Share my, our lessons from the road to re:Invent
naospon
0
150
Iceberg Meetup Japan #1 : Iceberg and Databricks
databricksjapan
0
370
IoTシステム開発の複雑さを低減するための統合的アーキテクチャ
kentaro
1
120
Change Managerを活用して本番環境へのセキュアなGUIアクセスを統制する / Control Secure GUI Access to the Production Environment with Change Manager
yuj1osm
0
100
Featured
See All Featured
Code Reviewing Like a Champion
maltzj
521
39k
Thoughts on Productivity
jonyablonski
69
4.5k
Reflections from 52 weeks, 52 projects
jeffersonlam
348
20k
How STYLIGHT went responsive
nonsquared
98
5.4k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
30
4.6k
Documentation Writing (for coders)
carmenintech
67
4.6k
The Art of Programming - Codeland 2020
erikaheidi
53
13k
A Tale of Four Properties
chriscoyier
158
23k
A designer walks into a library…
pauljervisheath
205
24k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
7
640
Testing 201, or: Great Expectations
jmmastey
42
7.2k
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発生時、どのようなプロセスが存在していたか ◦ どのプロセスが殺されたか