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
7
3.4k
MySQLのOOMと戦った話
ryuichi1208
July 20, 2024
Tweet
Share
More Decks by ryuichi1208
See All by ryuichi1208
AI前提のサービス運用について再考する
ryuichi1208
6
1.3k
A Shallow Dive into the World of TCP
ryuichi1208
1
580
入門リトライ
ryuichi1208
19
7.3k
超入門SRE 2025
ryuichi1208
4
1.4k
Goで作って学ぶWebSocket
ryuichi1208
5
3.7k
コード化されていない稼働中のサーバを移設_再構築する技術
ryuichi1208
20
13k
AI前提のサービス運用ってなんだろう?
ryuichi1208
9
1.9k
入門 バックアップ
ryuichi1208
22
10k
効果的なオンコール対応と障害対応
ryuichi1208
9
3.9k
Featured
See All Featured
Typedesign – Prime Four
hannesfritz
42
2.8k
Making the Leap to Tech Lead
cromwellryan
134
9.5k
We Have a Design System, Now What?
morganepeng
53
7.7k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
358
30k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Mobile First: as difficult as doing things right
swwweet
223
9.9k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.8k
Optimising Largest Contentful Paint
csswizardry
37
3.4k
A designer walks into a library…
pauljervisheath
207
24k
What’s in a name? Adding method to the madness
productmarketing
PRO
23
3.6k
Balancing Empowerment & Direction
lara
2
550
The Pragmatic Product Professional
lauravandoore
36
6.8k
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とかは有効にしておくと便利 まとめ