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
MySQLのOOMと戦った話
ryuichi1208
July 20, 2024
More Decks by ryuichi1208
See All by ryuichi1208
入門 再発防止策
ryuichi1208
17
6.8k
金曜日デプロイ、するかしないか.pdf
ryuichi1208
1
71
会話で作る信頼性
ryuichi1208
0
180
シグナル(Unix)と仲良くなる
ryuichi1208
1
43
AI前提のサービス運用について再考する
ryuichi1208
6
1.4k
A Shallow Dive into the World of TCP
ryuichi1208
1
670
入門リトライ
ryuichi1208
20
8.2k
超入門SRE 2025
ryuichi1208
4
1.5k
Goで作って学ぶWebSocket
ryuichi1208
5
4.2k
Featured
See All Featured
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
162
16k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
254
22k
Public Speaking Without Barfing On Your Shoes - THAT 2023
reverentgeek
1
410
The Limits of Empathy - UXLibs8
cassininazir
1
340
Accessibility Awareness
sabderemane
1
130
Highjacked: Video Game Concept Design
rkendrick25
PRO
1
380
How to build a perfect <img>
jonoalderson
1
5.6k
svc-hook: hooking system calls on ARM64 by binary rewriting
retrage
2
280
Evolving SEO for Evolving Search Engines
ryanjones
0
210
Getting science done with accelerated Python computing platforms
jacobtomlinson
2
220
Test your architecture with Archunit
thirion
1
2.3k
StorybookのUI Testing Handbookを読んだ
zakiyama
31
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とかは有効にしておくと便利 まとめ