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
MySQLのOOMと戦った話
Search
ryuichi1208
July 20, 2024
4
2.7k
MySQLのOOMと戦った話
ryuichi1208
July 20, 2024
Tweet
Share
More Decks by ryuichi1208
See All by ryuichi1208
AI前提のサービス運用ってなんだろう?
ryuichi1208
1
140
効果的なオンコール対応と障害対応
ryuichi1208
6
3.1k
コロナ禍とその後:地方エンジニアが学んだキャリア戦略の変遷
ryuichi1208
3
260
入門オンコール対応
ryuichi1208
7
3.3k
障害対応を楽しむ7つのコツ
ryuichi1208
7
4.5k
超入門 SRE
ryuichi1208
8
3.6k
SLO Docsのすゝめ
ryuichi1208
7
2.9k
SMTPでのOpenTelemetryの可能性を考えてみる
ryuichi1208
7
2.7k
実録_マルチテナント環境でのGmailガイドライン対応
ryuichi1208
9
2.1k
Featured
See All Featured
Building Applications with DynamoDB
mza
90
6k
Imperfection Machines: The Place of Print at Facebook
scottboms
263
13k
Making Projects Easy
brettharned
113
5.8k
Six Lessons from altMBA
skipperchong
26
3.4k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
36
2.1k
How to Ace a Technical Interview
jacobian
274
23k
Building Better People: How to give real-time feedback that sticks.
wjessup
359
19k
Typedesign – Prime Four
hannesfritz
39
2.3k
Designing Experiences People Love
moore
138
23k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
26
1.9k
Fontdeck: Realign not Redesign
paulrobertlloyd
80
5.1k
KATA
mclloyd
27
13k
Transcript
1 MySQLのOOMと戦った話 渡部 ⿓⼀ Road to SRE NEXT@広島 渡部⿓⼀
技術部プラットフォームグループ 2021年 中途入社 2 自己紹介 渡部 龍一 Watanabe Ryuichi •
ロール: SRE • 仙台から来ました(楽天ファンです ) • YAPC::HiroshimaでEOLの話をしてました • Mackerelアンバサダー
3 “MySQLがOOM Killerされた”
4 “どうなるか”
5 • データベースはサービスにおいて最もクリティカルなロールの⼀つ • マルチプライマリやリードレプリカが対象であってもOOM Killerによる死はサービス 側で影響がでる ◦ プライマリのフェールオーバーまでにかかる時間書き込みできない ◦
リードレプリカの死を検知しても即座に別のレプリカに繋ぐことはTCPを使っている以上難 しい ◦ バッファープールも何も乗らずに起動する(or 設定で変更は可能)のでクエリが遅い どうなるか
6 “起きないようにしたい”
7 • OOM(Out Of Memory) は、コンピュータシステムにおいて利⽤可能なメモリが不 ⾜し、プロセスが必要なメモリを確保できない状態を指す • メモリの過剰使⽤やメモリリークが原因となりがち •
OOM Killerとは ◦ OOM Killer は、Linuxカーネルに組み込まれている機能 ◦ システムがメモリ不⾜の状態になったときに、システム全体の安定性を保つためにプロセス を強制終了する機能 OOMとは?
8 “メモリの使⽤を制限しよう!”
9 “MySQLの取りうるメモリサイズ”
10
11 “搭載メモリサイズ以下になればOK?”
12 “そんなことはない”
13 “malloc”
14 • glibc/malloc ◦ 動的メモリを確保するための標準ライブラリ ▪ malloc(3)、free(3) ◦ https://bugs.mysql.com/bug.php?id=100704 ◦
内部で管理されるヒープメモリプールを使⽤して効率的なメモリ管理 ▪ 詳しくは「malloc動画」で検索! • google/tcmalloc ◦ Googleによって開発された⾼性能なメモリアロケータであり ◦ マルチスレッド環境での効率的なメモリ管理を⽬的としている ◦ 他の選択肢としてはjemalloc/jemallocとかもある malloc
15 “virtual memory size”
16 • virtual memory sizeとは ◦ プロセスがアクセスできるメモリ領域 ◦ プロセスがマッピングしたすべてのメモリ領域の合計(mallocして使わないとrssは増えない) •
Mackerelを⽤いて使⽤量を監視しつつ閾値以上になったらVSSを⼤量消費しているプ ロセスを再起動 • ありがちだったのが⻑すぎるトランザクションが消費してたりしたので監視 virtual memory size
17
18 “万事解決!”
19 “ではない”
20 “FTSのテーブルのrestore中にOOM”
21 • mydumperを使ってFullTextインデックスがあるテーブルをdump/restoreするとOOM Killerで死 • パラメータを⾊々変えて⾒ても発⽣していた(MySQL 5.7.36) ◦ 8.0にしたので今は起きないかもと思いつつバグレポート探すとまだまだ出てくる... ▪
https://bugs.mysql.com/bug.php?id=100704 • MySQL Bugsをみると似たような事象の報告が多数あったが特に解決まで⾄らずに数 年とか経っていそうだったので⼀旦別⽅針で進めることに... Full Text Index(未解決)
22 “まとめ”
23 • データベースはサービスにおいて最もクリティカルなロールの⼀つOOMで殺されたく ない!!! • mallocやvirtual memoryあたりのキーワードは覚えておくと今後も良いかも • Auroraでも起きるのでaurora_oom_responseとかは有効にしておくと便利 まとめ