$30 off During Our Annual Pro Sale. View Details »
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
MySQLのOOMと戦った話
Search
ryuichi1208
July 20, 2024
7
3.5k
MySQLのOOMと戦った話
ryuichi1208
July 20, 2024
Tweet
Share
More Decks by ryuichi1208
See All by ryuichi1208
AI前提のサービス運用について再考する
ryuichi1208
5
1.3k
A Shallow Dive into the World of TCP
ryuichi1208
1
600
入門リトライ
ryuichi1208
20
7.6k
超入門SRE 2025
ryuichi1208
4
1.4k
Goで作って学ぶWebSocket
ryuichi1208
5
3.9k
コード化されていない稼働中のサーバを移設_再構築する技術
ryuichi1208
20
14k
AI前提のサービス運用ってなんだろう?
ryuichi1208
9
1.9k
入門 バックアップ
ryuichi1208
22
11k
効果的なオンコール対応と障害対応
ryuichi1208
9
4.1k
Featured
See All Featured
Designing Experiences People Love
moore
142
24k
Site-Speed That Sticks
csswizardry
13
980
Docker and Python
trallard
46
3.7k
Balancing Empowerment & Direction
lara
5
780
Six Lessons from altMBA
skipperchong
29
4.1k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
Side Projects
sachag
455
43k
Bash Introduction
62gerente
615
210k
GraphQLの誤解/rethinking-graphql
sonatard
73
11k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
35
2.3k
How STYLIGHT went responsive
nonsquared
100
5.9k
Making the Leap to Tech Lead
cromwellryan
135
9.6k
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とかは有効にしておくと便利 まとめ