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
3.7k
7
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
MySQLのOOMと戦った話
ryuichi1208
July 20, 2024
More Decks by ryuichi1208
See All by ryuichi1208
AIでサービス運用はどう変わるのか
ryuichi1208
0
160
入門 再発防止策
ryuichi1208
17
7.4k
金曜日デプロイ、するかしないか.pdf
ryuichi1208
1
75
会話で作る信頼性
ryuichi1208
0
180
シグナル(Unix)と仲良くなる
ryuichi1208
1
50
AI前提のサービス運用について再考する
ryuichi1208
6
1.5k
A Shallow Dive into the World of TCP
ryuichi1208
1
680
入門リトライ
ryuichi1208
20
8.3k
超入門SRE 2025
ryuichi1208
4
1.6k
Featured
See All Featured
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
128
56k
Into the Great Unknown - MozCon
thekraken
41
2.6k
The Hidden Cost of Media on the Web [PixelPalooza 2025]
tammyeverts
2
350
What's in a price? How to price your products and services
michaelherold
247
13k
HTML-Aware ERB: The Path to Reactive Rendering @ RubyCon 2026, Rimini, Italy
marcoroth
2
330
Rails Girls Zürich Keynote
gr2m
96
14k
How Software Deployment tools have changed in the past 20 years
geshan
0
34k
SEO Brein meetup: CTRL+C is not how to scale international SEO
lindahogenes
1
2.8k
How to Grow Your eCommerce with AI & Automation
katarinadahlin
PRO
1
230
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
9
1.4k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
201
75k
Mozcon NYC 2025: Stop Losing SEO Traffic
samtorres
1
370
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とかは有効にしておくと便利 まとめ