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
170
恐怖の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
5
2.9k
俺とVSCode Python Debugger Extension
sat
PRO
1
180
コード再利用のしくみ ライブラリ
sat
PRO
3
49
AWKへの愛を語る
sat
PRO
3
520
syncコマンドのデータ同期 完了待ちやエラー検出
sat
PRO
0
64
動作中のLinux環境の全メモリを見る
sat
PRO
1
96
Linuxの時間を10秒止める
sat
PRO
2
210
プロセスへのメモリ割り当て4 - 実際に使うときにメモリを獲得するデマンドページング(実践編)
sat
PRO
1
120
プロセスへのメモリ割り当て(3) 実際に使うときにメモリを獲得するデマンドページング
sat
PRO
1
73
Other Decks in Technology
See All in Technology
Terraform Stacks入門 #HashiTalks
msato
0
360
CysharpのOSS群から見るModern C#の現在地
neuecc
2
3.6k
AWS Lambda のトラブルシュートをしていて思うこと
kazzpapa3
2
200
リンクアンドモチベーション ソフトウェアエンジニア向け紹介資料 / Introduction to Link and Motivation for Software Engineers
lmi
4
300k
あなたの知らない Function.prototype.toString() の世界
mizdra
PRO
2
380
Storybook との上手な向き合い方を考える
re_taro
5
920
Lexical Analysis
shigashiyama
1
150
Introduction to Works of ML Engineer in LY Corporation
lycorp_recruit_jp
0
150
Amazon CloudWatch Network Monitor のススメ
yuki_ink
1
210
Making your applications cross-environment - OSCG 2024 NA
salaboy
0
200
Python(PYNQ)がテーマのAMD主催のFPGAコンテストに参加してきた
iotengineer22
0
540
RubyのWebアプリケーションを50倍速くする方法 / How to Make a Ruby Web Application 50 Times Faster
hogelog
3
950
Featured
See All Featured
Build The Right Thing And Hit Your Dates
maggiecrowley
33
2.4k
Teambox: Starting and Learning
jrom
133
8.8k
YesSQL, Process and Tooling at Scale
rocio
169
14k
Bash Introduction
62gerente
608
210k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
93
16k
Designing for humans not robots
tammielis
250
25k
Adopting Sorbet at Scale
ufuk
73
9.1k
How to Think Like a Performance Engineer
csswizardry
20
1.1k
Being A Developer After 40
akosma
87
590k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
131
33k
Gamification - CAS2011
davidbonilla
80
5k
We Have a Design System, Now What?
morganepeng
50
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発生時、どのようなプロセスが存在していたか ◦ どのプロセスが殺されたか