MongoDBが遅いときの切り分け方法

Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved
MongoDBが遅いときの切り分け方法
コンサルタント
渡部徹太郎
1

自己紹介
2
{"ID" ："fetaro"
"名前"："渡部徹太郎"
"研究"："東京工業大学でデータベースと情報検索の研究
(@日本データベース学会)"
"仕事"：{前職:["証券会社のオンライントレードシステムのWeb基盤",
"オープンソースなら何でも。主にMongoDB,NoSQL"],
現職:["大手Web企業の横断分析基盤,Exadata,Hortonworks,EMR"]
副業:["MongoDBコンサルタント" ]}
"エディタ"："emacs派",
"趣味"： ["自宅サーバ","麻雀"]
}

はじめに
MongoDBは速い？
• MongoDBはNoSQLだからRDBより速い？
• シャーディングすれば単体構成より速い？
3

はじめに
MongoDBは速い？→ケースに依る
• MongoDBはNoSQLだからRDBより速いわけではない
– RDBとは提供している機能が違う
• トランザクション、JOIN、副問合せ等のRDBで遅くなりがちな
複雑なクエリはMongoDBは提供していない
• データモデルが違う、保証する整合性が違う
– シンプルなクエリであればRDBとMongoDBでそれほど差はな
い
• MongoDBはオーバーヘッドが少ない分速いが
• 結局はディスクIOをどれだけ減らせるか
• シャーディングすれば単体構成より速いとは限らない
– ボトルネックが分散するようにシャーディングを組まないとい
けない
– データだけ分散しても駄目。クエリの分散まで考える必要あり
– クエリが分散してもボトルネックが解消しないと駄目。
• 例）ネットワークネックならばIOが減っても意味なし
4

はじめに
MongoDBを速くしたければRDBを勉強すべき
• MongoDBだから特別なことはほとんどない
• MongoDBはRDBに似ている
– CassandraやDynamoDB 等はRDBと大きく違う
• 8割はRDBのパフォーマンスチューニングの知識でカバーで
きる
– インデックス、クエリ最適化、キャッシュ、データ圧縮、WAL、
リードレプリカ、パーティショニング
• 残り2割はMongoDB特有
– データ構造(JSON)が性能に与える影響
– シャーディング
今回の発表は、RDBにも通用する一般的な話が多いです
5

アジェンダ
• 性能問題との向き合い方
• 解くべき問題の明確化
• 根本原因の特定
• IOボトルネックの解消
– MMAPv1の場合
– WiredTigerの場合
6

性能問題との向き合い方
7

性能問題を考える場合の思考順序
1. 解くべき問題の明確化
– 本当にMongoDBが遅いのか？
• アプリやネットワークに問題はないか
– どのクエリが遅いのか？
• 読み込み, 書き込み, 集計
– 何を改善したいのか（性能要件の明確化）
• レスポンスタイム,スループット
2. 根本原因の特定
– リソースが枯渇しているのか?
• CPU, メモリ/ディスク, NW帯域
– 非効率な処理をしていないか？
• ロック開放待ち、フェッチ、NWラウンドトリップ
3. 根本原因の解消
– リソース枯渇の場合
1. 単体構成の性能を最大限まで上げる→ 8割これでいける！
2. リードレプリカ→おまけ
3. シャーディング→最後の手段
– 処理が非効率の場合
• アプリを見直す
8

性能問題調査でよくある間違い
• よくある勘違い
– CPU使用率が高すぎることが原因だ！
• →いいことです
– メモリ使用率が高すぎることが原因だ！
• →溢れてIOが発生していなければ、いいことです
• 全てのリソースを最大限まで使えたら完璧なチューニング
• つまり
– CPU使用率100%
– メモリ使用率100%
– ディスクI/O使用率100%
– NW使用率100%
を同時に見対している状態
9
考え方の整理はこの本がおすすめ

解くべき問題の明確化
10

本当にMongoDBが遅いのか？
• 「画面の応答が遅い」「アプリの実行時間がながい」
→本当にMongoDBが遅いんですか？
• ミドルウェアのログから各レイヤでの処理時間を計測
– 大多数のケースで、これが整理できていない
11
ブラウザ Webアプリ MongoDB
t0
t1
t2
t3
t4
t5
t6
本当にココ
が遅いの
か？

MongoDBの何が遅いのか
• 何のクエリが遅いのか？
– 読み取り、書き込み、集計
– 可能であればクエリを特定する
• 何の指標が遅いのか？
– レスポンスタイムが遅い
• スロークエリログを見てクエリ応答時間をみる
• プロファイラを有効にしてクエリの情報を見る
– スループットが低い
• mongostatを見て、単位時間あたりの処理量をみる
• mongotopを見て、コレクションごとの処理量をみる
12

遅い箇所の調べ方
• スロークエリログ
– 設定ファイルで起動前に指定する
– デフォルトで100msを超えるクエリは、ログに出力される
• プロファイラ
– 起動後にMongoShellなどで接続して一時的にプロファイラを有効
にする
13
2015-07-10T04:09:01.113+0900 I COMMAND [conn1] command test.$cmd command: insert
{ insert: "mycol", documents: [ { _id: ObjectId('559ec6cd959e8f181ae68153'), name:
"watanabe" } ], ordered: true } keyUpdates:0 writeConflicts:0 numYields:0
reslen:40 locks:{ Global: { acquireCount: { r: 2, w: 2 } }, Database:
{ acquireCount: { w: 2 } }, Collection: { acquireCount: { w: 2 } } } 120ms
#プロファイラを有効にする
> db.setProfilingLevel(1) { "was" : 0, "slowms" : 100, "ok" : 1 }
#中身を見る
> db.system.profile.find()

• mongostatコマンド
• mongotopコマンド
14
$./bin/mongostat connected to: 127.0.0.1
insert query update delete getmore command flushes mapped vsize res ...
40 *0 *0 *0 0 1|0 1 12g 24.4g 51m ...
30 *0 *0 *0 0 1|0 0 12g 24.4g 52m ...
32 *0 *0 *0 0 1|0 0 12g 24.4g 53m ...
$ ./bin/mongotop
ns total read write 2015-07-10T04:56:52+09:00
mydb.mycol 6ms 6ms 0ms
admin.system.roles 0ms 0ms 0ms
admin.system.version 0ms 0ms 0ms
ns total read write 2015-07-10T04:56:53+09:00
mydb.mycol 44ms 44ms 0ms
admin.system.roles 0ms 0ms 0ms
admin.system.version 0ms 0ms 0ms

• MongoDB CloudManager(旧OpsManager, MMS)を使って
も良い
– あらかじめMongoDBに特化したメトリックがとられる
– 監視項目を設計しなくて良い
15

根本原因の特定
16

• 結論は２種類
– ボトルネックが有る
or
– ボトルネックが無い
• ボトルネックが有る
– CPU 1core張り付き、高ロードアベレージ→1.CPUボトルネック
– メモリ空き容量0、ディスクIO頻発→2.IOボトルネック
– ネットワーク流量逼迫(80%超え) →3.NWボトルネック
• ボトルネックがない
– MongoDBに本気を出させることが出来ていない→4.処理の非効率
17

1.CPUボトルネック
• 概要
– Aggregationや算術演算で、CPUを使う処理が多い場合にボトルネックになるこ
とがある。
– CPUボトルネックはIOやネットワークにボトルネックがない場合がおおいため、
どちらかといえば健全な状態。
• チェック方法
– 1コアに注目したとき、使用率のuserとsysの合計が100%になっていないか
• 全体のCPU使用率50%、25%、12.5%は要注意
– 50%→2core中1つが100%
– 25%→4core中1つが100%
– 12.5%→8core中1つが100%
• 例 ) $ dstat -c -C 0,1,2,3,total
– ロードアベレージはコア数以上になっていないか
• 解消方法
– 応答性能向上
• マルチスレッドで動作する演算ならばコア数を上げる
• そうでないならCPUクロック数を上げる
– スループット向上
• コア数を上げる
18

2.ネットワークボトルネック
• 概要
– アプリケーションに対してMongoDBが大量のデータを返す場合に
多い。
– 他には、レプリケーションのoplog転送量が想定以上に肥大化し、
ネットワークを圧迫している場合もある
– mongostatやOSのdstatコマンドにより、ネットワークの流量を監
視し、ネットワークのキャパシティ(1Gbit, 10GBit等)に対して流
れている流量が限界に達していないか？
– 1Gbit/sの設定であれば800Mbit/sあたりで限界
• 解消方法
– ネットワークを太くする
– 射影してアプリケーションで受け取るデータを減らす
– oplogが肥大化が原因の場合は、肥大化を引き起こすオペレーショ
ンに注意する
• multi updateやremove、配列の$popや$pullなど
詳細は https://enterprisezine.jp/dbonline/detail/8095
19

3.IOボトルネック
• 概要
– メモリ上にデータがなく、ディスクにデータを読みに行くことが頻発
すると、ディスクはメモリに対して100倍程度遅いため、全体として処
理速度が低下する。
– MongoDB（というかDB全般）では大半がこのケース
– OSのiostatコマンドで、 avgqusz, await, %util が高い。 rMB/s、
wMB/sがいつもより多い。CPUのiowaitが多い
– キャッシュが溢れている
• MMAPv1の場合、mongostatのページフォルトが多い
• WiredTigerの場合、キャッシュへの読み込み累積値(bytes read into
cache)が物理メモリ量を超えて増え続けている
• 解消方法
– 次ページで説明
20

3.IOボトルネック - 解消方法
1. インデックス
– RDBと同じB-Treeでインデックスがあるので、同じ考え方でインデックスを設
計すれば良い
– 実行計画の見方
• db.mycol.find().explain() →実行はしないで計画を表示
• db.mycol.find().explain("executionStats") →実際に実行する
2. メモリキャッシュ
– メモリを駆使してIOボトルネックを解消するには
MongoDBのアーキテクチャの理解が必須
– ストレージエンジンによって全く違う
• MMAPv1 : メモリ管理をOSまかせ
• WiredTiger : MongoDBが買収した最先端のストレージ
– →後半でガッツリ説明
21

4. 処理の非効率
• 書き込みが遅い
– ロック開放待ちになっている(MMAP限定)
– バッチインサートしていない
– Write Concernの値が必要以上に大きい
– WiredTigerの場合は同時に実行できるクエリ数にそれぞれ128
の制限(Ticketsという)があり、それに引っかかっていないか
• db.serverStatus().wiredTiger.concurrentTransactions
• 読み込みが遅い
– フェッチが細かすぎる
– 同時実行
– 同時実行クエリ数制限
22

IOボトルネックの解消
MMAPv1の場合
23

読み込み時の動き(MMAP)
• 起動時に、mongodは、OSに対して、
データベースファイルをメモリにmapするように依頼する
– システムコールmmap()を実行
• 起動直後はメモリは空
24
doc1 doc3index doc2
ディスク
メモリ
mongodプロセス
OSが管理
ブロック
データベースファイル
mmap(
)

• mongodがdoc1を読もうとすると
– mongodは、OSに対して、ブロックの取得を依頼
– OSは、メモリ上にないので、ディスクから読む（＝遅い）
• ページフォルト発生
• doc1と関連するindexのブロックだけが読み込まれる
25
doc1 doc3index doc2
ディスク
メモリ
doc1
mongodプロセス
index

• doc1をもう一度読む
– mogodは、OSに対して、ブロックの取得を依頼
– OSは、メモリにあるので、メモリから返す応答する（＝速い）
26
doc1 doc3index doc2
ディスク
メモリ
doc1
mongodプロセス
index

• doc2を読むと
– indexはメモリにあるが、doc2はメモリにないので、ディスク
から読む(遅い)
27
doc1 doc3index doc2
ディスク
メモリ
doc1
mongodプロセス
doc2index

• doc3を読むと
– doc3はメモリにないので、ディスクから読む
– 空きがないので、最もアクセス頻度の低いブロックを追い出す（ス
ワップアウト）
28
doc1 doc3index doc2
ディスク
メモリ
mongodプロセス
index doc3

MMAPで、IOネックで、読み込みが遅いときの原因候補
• インデックス
– インデックスが使われていない
– インデックスが有効ではない
• フルスキャンの方が効率が良い
• hint()の利用を検討
• キャッシュ
– 起動直後でキャッシュが空
– ワーキングセット（インデックスと使うデータ）がメモリに対して大す
ぎる
– OSにメモリの空きがなく、mongodがメモリをもらえていない
– 射影してもメモリにはドキュメント全体がのるが、その動きを知らない
• db.mycol.find({},{"name":1}) としてもname以外のデータもメモリに
乗る
– ブロックサイズがドキュメントに対して大きすぎて無駄が多い
29
doc1 無駄

書き込み時の動き(MMAP)ジャーナルなし
• update doc1を実行すると
– mongodは、OSに対して、データベース単位のロックを依頼して更新
• MongoDB 3.0ではコレクションレベルでロック
– 他のスレッドからの書き込みは待たされる（＝遅くなる）
– メモリ上にindexとdoc1があればメモリ上で更新は完結。なければIO発生
– 非同期でディスクに書き戻し(60秒に一回)
• クラッシュすると最悪60秒間ロストする＆データベースファイルが破損する
30
doc1 doc3index doc2
ディスク
メモリmongodプロセス
doc2index'
スレッドスレッド
書き込みを待たされる2.ロック・
doc1とindexを更
新 ×
1.アプリからクエリ4.アプリに返却
ロック開放
5.60秒に1回ディスクに書き戻し
fsync()
doc1'

書き込み時の動き(MMAP)ジャーナルあり
• update doc1
– ジャーナルファイルに更新内容を記載
• クラッシュしても100ms以内の変更は保持
• クラッシュしてもデータ破損自動修復
31
doc1 doc3index doc2
ディスク
メモリmongodプロセス
doc2
スレッド
2.ロックを取得
更新内容を追記
ジャーナル
ジャーナル
5.100msに1回flash
(j:trueなら即時)
4.アプリに返却
ロックを開放
1.アプリからクエリ
3. doc1とindexを
更新
6.60秒に1回ディス
クに書き戻し
doc1'index'

MMAPで、IOネックで、書き込みが遅いときの原因候補
– インデックスがある
• キャッシュ
– 更新するドキュメント・インデックスがメモリに無い
– ジャーナルとデータを同じディスクい書いている
– 全てのデータベースが同じディスクに書いている
– MongoDBのログをデータと同じディスクに書いている
– Write concertnで j:trueになっていてジャーナルの物理書き込みを待って
いる
– ドキュメントのサイズが大きくなり、物理移動が発生している
• 肥大化が起こると、そのコレクションでは、次からドキュメントサイズに余裕を
持って物理領域を取るようになる→Padding factorの増加
– データ移動が頻発し、データファイルがフラグメンテーションして、必要
以上にメモリを利用しなくてはならない
32
doc1 doc3index doc2
doc3index doc2 doc1'
doc1index doc2 doc3

IOボトルネックの解消
WiredTigerの場合
33

WiredTigerの基本
• WiredTigerとは
– MongoDB,Incが買収したストレージ
– MMAPv1を差し替えることができる
• MMAPv1との違い
– OS任せだったメモリキャッシュを、ある程度制御するようになっ
た
– 更新は、その場(in place)ではなく、新しいバージョンのドキュメ
ントを挿入して、ポインタを張り替えようになった(MVCC,CAS)
• ロックが無くなった（事実上ドキュメントレベルロックと同じ）
• データファイルのフラグメンテーションがなくなった
• データの肥大化による移動がなくなった
• 裏で、古いバージョンをマージする動作(eviction)をするようになった
• これらにより、複数スレッドでマルチコアを有効に使って、スルー
プットをあげられるようになった
– インデックスとデータが別ファイルになった
– データの圧縮ができるようになった（メモリ量は圧縮できない）
34

mongodプロセス
WiredTigerキャッシュ
WiredTigerの動き(たぶん正しい)
• 起動直後はWiredTigerキャッシュは空
35
doc1
doc
3index ディスク
メモリ
doc2
Readスレッド Writeスレッド
dirtyページ
cleanページ
on diskページ
root

mongodプロセス
• 読み込むとツリーが形成される
• ツリーのリーフはディスクのページ毎に読み込まれている
• 以下の例ではdoc1を読んでいるので、indexとdocが含まれるページがキャッシュにのる
36
doc1
doc
3index ディスク
メモリ
doc2
doc1index
root
dirtyページ
cleanページ
on diskページ

mongodプロセス
• さらにdoc2やdoc3を読むと、キャッシュにのる
37
doc1
doc
3index ディスク
メモリ
doc2
doc1index
root
doc
3
doc2 dirtyページ
cleanページ
on diskページ

mongodプロセス
• ここでトランザクションtx1でdoc1をdoc1'に更新しようとする
（説明を簡単にするため、index更新は図から省略)
– これは新しいツリーをつくる動きになる
• それとは別に、メモリ上のジャーナルに更新内容を書き込む
– 50ms毎にディスクにSnappyで圧縮されて永続化される
38
doc1
doc
3index ディスク
メモリ
doc2
doc1index
root
doc
3
doc2 doc1’
root(tx1)
dirtyページ
cleanページ
on diskページ
tx1
tx1
tdoc1→doc1'
ジャーナル
ジャーナル
doc1→doc1'

mongodプロセス
• tx1が終わる前に、doc1の読み込みトランザクションtx2が動き出
すと、古いドキュメントが見える
39
doc1
doc
3index ディスク
メモリ
doc2
doc1index
root
doc
3
doc2 doc1’
root(tx1)
dirtyページ
cleanページ
on diskページ
tx1
tx2
tx2
tx1
tdoc1→doc1'
doc1→doc1'
ジャーナル

mongodプロセス
• tx1がcommitした後に、tx3がdoc1を読みに行くと、
新しいdoc1' が見える
40
doc1
doc
3index ディスク
メモリ
doc2
doc1index
root
doc
3
doc2 doc1’
root(tx1)
dirtyページ
cleanページ
on diskページ
tx3
tx2
tx1
tx3
t
doc1→doc1'
ジャーナル

mongodプロセス
• 前回のチェックポイントから60秒経過するか、
ジャーナルが2GBを超えると、チェックポイントになる
• Evictionスレッドがcleanなページとdirtyなページをマージしてディス
クへ書き込む
41
doc1'
doc
3index ディスク
メモリ
doc2
doc1index
root
doc
3
doc2
Evictionスレッド
doc1’
root(tx1)
dirtyページ
cleanページ
on diskページ
doc1→doc1'
ジャーナル

mongodプロセス
• チェックポイントが終わると、古いツリーは消されて、
キャッシュとディスクが同期する
• ジャーナルは空になる
42
doc1'
doc
3index ディスク
メモリ
doc2
index
doc
3
doc2 doc1’
root(tx1)
dirtyページ
cleanページ
on diskページ
ジャーナル
（空）

WiredTigerで、IOネックで、書き込みが遅いときの原因候補
– インデックスがある
• キャッシュ
– 更新するドキュメント・インデックスがメモリに無い
– ジャーナルとデータを同じディスクい書いている
– 全てのデータベースが同じディスクに書いている
– MongoDBのログをデータと同じディスクに書いている
– Write concertnで j:trueになっていてジャーナルの物理書き込みを
待っている
– ドキュメントのサイズが大きくなり、物理移動が発生している
– データ移動が頻発し、データファイルがフラグメンテーションして、
必要以上にメモリを圧迫している
43

WiredTigerで、IOネックで、読み込みが遅いときの原因候補
– インデックスが使われていない
– インデックスが有効ではない
• キャッシュ
– 起動直後でキャッシュが空
– ワーキングセット（インデックスと使うデータ）がメモリに対して
大すぎる
• メモリ上は圧縮されないので注意！
– 射影してもメモリにはドキュメント全体がのるが、その動きを知ら
ない
– ブロックサイズがドキュメントに対して大きすぎて無駄が多い
– OSにメモリの空きがなく、mongodがメモリをもらえていない
– WiredTigerだからおそい。MMAPv1よりやることが多い。
– WiredTigerのキャッシュを割り当てすぎてファイルキャッシュに使
えない（次ページで詳細）
44

WiredTigerキャッシュにメモリを割り当てすぎることによるデメリット
– mongodそのものでOOMになる可能性がある
– リードが多い場合は、Wiredキャッシュよりも、データが圧縮されている
ファイルキャッシュに多くのドキュメントを載せたほうが効率が良い事がある
45
mongodプロセス
ディスク
メモリ
mongodそのものがつかうメモリ
Aggregation, Sort, 等
OS OSのファイルシステムキャッシュ
doc1
doc1
doc1
圧縮
圧縮
非圧縮
mongodの実メモリ
量
設定できるのは
ココだけ
空きメモリから
自動的に確保
2017/2/20更新: 「MongoDBのファイルキャッシュ」は存在しないため図から削
除

参考にした資料
• ちょっと古い公式説明資料。だいたい同じスライド
– http://www.slideshare.net/mongodb/mongo-db-
wiredtigerwebinar?ref=https%3A%2F%2Fwww.mongodb.co
m%2Fpresentations%2Fwebinar-a-technical-introduction-to-
wiredtiger
– http://www.slideshare.net/NorbertoLeite/mongodb-
wiredtiger-internals
– https://scs.hosted.panopto.com/Panopto/Pages/Viewer.aspx
?id=9a55027f-2b6c-48f4-86f6-73cc167619d0
• 新しい公式セミナ。WiredTigerで使っている様々な工夫を詳細に
説明している。
– https://www.mongodb.com/presentations/mongodb-europe-
2016-building-wiredtiger
• ブログ。WiredTigerのstatの見方や、パフォーマンスチューニング
について解説している
– http://www.developer.com/db/tips-for-mongodb-wiredtiger-
performance-tuning.html
46

MongoDBが遅いときの切り分け方法

MongoDBが遅いときの切り分け方法

Recommended

More Related Content

What's hot

What's hot(20)

Viewers also liked

Viewers also liked(6)

Similar to MongoDBが遅いときの切り分け方法

Similar to MongoDBが遅いときの切り分け方法(20)

More from Tetsutaro Watanabe

More from Tetsutaro Watanabe(18)

Recently uploaded

Recently uploaded(12)

MongoDBが遅いときの切り分け方法