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
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
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
47
システム強制終了時に ファイルシステムの整合性を保つ ~ ジャーナリング編 ~
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
論文紹介:Pixal3D (SIGGRAPH 2026)
tenten0727
0
720
「使われるデータ基盤」を目指してデータアナリストとワークショップをやった話
jackojacko_
2
850
20260528_生成AIを専属DSに_Howの次にすべきことを考える
doradora09
PRO
0
190
AIのために、AIを使った、Effect-TSからの脱却 〜テストを活用した安全なリファクタリングの進め方〜
bitkey
PRO
1
540
自作エディターをOSSにして分かった、一人に刺さる開発が世界を動かす理由
shinyasaita
1
310
AI時代に改めて考える、ドメイン駆動設計 - モデリングが「AIへの共通言語」になる
littlehands
7
2.3k
JavaScript実装の自作プログラミング言語をTypeScript実装に移行した話
keisukeikeda
1
150
Amazon CloudFrontにおけるAIボットアクセス制御のポイント
kizawa2020
4
260
CloudFront VPCオリジンとVPC Latticeサービスの内部ALBをマルチアカウントで一元利用しよう
duelist2020jp
5
220
コーポレートサイトのアクセシビリティ改善とJIS準拠への実践
lycorptech_jp
PRO
2
140
実践 TanStack Start ― 新規プロダクトを開発して確立した、サーバーとクライアント境界の設計パターン / Practical TanStack Start Server-Client Boundary Patterns
kaminashi
2
300
Typiaで配信JSONの安全性を構造的に担保する(TSKaigi2026)
righttouch
PRO
1
160
Featured
See All Featured
Leveraging Curiosity to Care for An Aging Population
cassininazir
1
240
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
34
2.7k
4 Signs Your Business is Dying
shpigford
187
22k
How to build an LLM SEO readiness audit: a practical framework
nmsamuel
1
750
職位にかかわらず全員がリーダーシップを発揮するチーム作り / Building a team where everyone can demonstrate leadership regardless of position
madoxten
62
54k
Imperfection Machines: The Place of Print at Facebook
scottboms
270
14k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
133
19k
Marketing Yourself as an Engineer | Alaka | Gurzu
gurzu
0
200
Art, The Web, and Tiny UX
lynnandtonic
304
21k
Docker and Python
trallard
47
3.8k
Typedesign – Prime Four
hannesfritz
42
3k
The Cost Of JavaScript in 2023
addyosmani
55
9.9k
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発生時、どのようなプロセスが存在していたか ◦ どのプロセスが殺されたか