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
230
恐怖の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
デバイスにアクセスするデバイスファイル
sat
PRO
1
27
ファイルシステムのデータを ブロックデバイスへの操作で変更
sat
PRO
1
19
デバイスドライバ
sat
PRO
0
27
マルチスレッドの実現方法 ~カーネルスレッドとユーザスレッド~
sat
PRO
2
70
共有メモリ
sat
PRO
3
56
マルチスレッドプログラム
sat
PRO
3
46
Linuxのブートプロセス initramfs編
sat
PRO
2
56
Linuxのブートプロセス
sat
PRO
6
160
シェルのジョブ
sat
PRO
1
37
Other Decks in Technology
See All in Technology
SRE本出版からまもなく10年!〜これまでに何が起こり、これから何が起こるのか〜
katsuhisa91
PRO
0
350
激動の一年を通じて見えてきた「技術でリードする」ということ
ktr_0731
8
8.4k
マーケットプレイス版Oracle WebCenter Content For OCI
oracle4engineer
PRO
3
720
Cursorをチョッパヤインタビューライターにチューニングする方法 / how to tuning cursor for interview write
shuzon
2
270
テストコードにはテストの意図を込めよう(2025年版) #retechtalk / Put the intent of the test 2025
nihonbuson
PRO
11
2.1k
4社統合におけるマスタデータ管理に立ち向かう / Towards master data management in the four-company integration
carta_engineering
0
230
newmo の創業を支える Software Architecture と Platform Engineering
110y
5
580
本番環境への影響リスクが低い Real Application Testing (SQL Performance Analyzer) の実施方法の検討と実践
jri_narita
0
200
Why every SwiftUI developer should care about the Environment - iOSKonf25
peterfriese
0
160
GPU 클라우드 환경에서의 회복탄력적 AI 운영 : 훈련 및 추론을 위한 견고한 아키텍처와 전략
inureyes
PRO
0
130
名単体テスト 禁断の傀儡(モック)
iwamot
PRO
1
320
[新卒向け研修資料] テスト文字列に「うんこ」と入れるな(2025年版)
infiniteloop_inc
14
47k
Featured
See All Featured
[RailsConf 2023] Rails as a piece of cake
palkan
55
5.5k
Product Roadmaps are Hard
iamctodd
PRO
53
11k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
105
19k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
10
810
The Straight Up "How To Draw Better" Workshop
denniskardys
233
140k
Git: the NoSQL Database
bkeepers
PRO
430
65k
Optimizing for Happiness
mojombo
378
70k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
26k
Visualization
eitanlees
146
16k
Into the Great Unknown - MozCon
thekraken
38
1.8k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
50k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
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発生時、どのようなプロセスが存在していたか ◦ どのプロセスが殺されたか