SlideShare a Scribd company logo
1 of 46
Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved
MongoDBが遅いときの切り分け方法
コンサルタント
渡部 徹太郎
1
Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved
自己紹介
2
{"ID" :"fetaro"
"名前":"渡部 徹太郎"
"研究":"東京工業大学でデータベースと情報検索の研究
(@日本データベース学会)"
"仕事":{前職:["証券会社のオンライントレードシステムのWeb基盤",
"オープンソースなら何でも。主にMongoDB,NoSQL"],
現職:["大手Web企業の横断分析基盤,Exadata,Hortonworks,EMR"]
副業:["MongoDBコンサルタント" ]}
"エディタ":"emacs派",
"趣味": ["自宅サーバ","麻雀"]
}
Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved
はじめに
MongoDBは速い?
• MongoDBはNoSQLだからRDBより速い?
• シャーディングすれば単体構成より速い?
3
Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved
はじめに
MongoDBは速い?→ケースに依る
• MongoDBはNoSQLだからRDBより速い わけではない
– RDBとは提供している機能が違う
• トランザクション、JOIN、副問合せ等のRDBで遅くなりがちな
複雑なクエリはMongoDBは提供していない
• データモデルが違う、保証する整合性が違う
– シンプルなクエリであればRDBとMongoDBでそれほど差はな
い
• MongoDBはオーバーヘッドが少ない分速いが
• 結局はディスクIOをどれだけ減らせるか
• シャーディングすれば単体構成より速い とは限らない
– ボトルネックが分散するようにシャーディングを組まないとい
けない
– データだけ分散しても駄目。クエリの分散まで考える必要あり
– クエリが分散してもボトルネックが解消しないと駄目。
• 例)ネットワークネックならばIOが減っても意味なし
4
Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved
はじめに
MongoDBを速くしたければRDBを勉強すべき
• MongoDBだから特別なことはほとんどない
• MongoDBはRDBに似ている
– CassandraやDynamoDB 等はRDBと大きく違う
• 8割はRDBのパフォーマンスチューニングの知識でカバーで
きる
– インデックス、クエリ最適化、キャッシュ、データ圧縮、WAL、
リードレプリカ、パーティショニング
• 残り2割はMongoDB特有
– データ構造(JSON)が性能に与える影響
– シャーディング
今回の発表は、RDBにも通用する一般的な話が多いです
5
Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved
アジェンダ
• 性能問題との向き合い方
• 解くべき問題の明確化
• 根本原因の特定
• IOボトルネックの解消
– MMAPv1の場合
– WiredTigerの場合
6
Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved
性能問題との向き合い方
7
Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved
性能問題を考える場合の思考順序
1. 解くべき問題の明確化
– 本当にMongoDBが遅いのか?
• アプリやネットワークに問題はないか
– どのクエリが遅いのか?
• 読み込み, 書き込み, 集計
– 何を改善したいのか(性能要件の明確化)
• レスポンスタイム,スループット
2. 根本原因の特定
– リソースが枯渇しているのか?
• CPU, メモリ/ディスク, NW帯域
– 非効率な処理をしていないか?
• ロック開放待ち、フェッチ、NWラウンドトリップ
3. 根本原因の解消
– リソース枯渇の場合
1. 単体構成の性能を最大限まで上げる→ 8割これでいける!
2. リードレプリカ→おまけ
3. シャーディング→最後の手段
– 処理が非効率の場合
• アプリを見直す
8
Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved
性能問題調査でよくある間違い
• よくある勘違い
– CPU使用率が高すぎることが原因だ!
• →いいことです
– メモリ使用率が高すぎることが原因だ!
• →溢れてIOが発生していなければ、いいことです
• 全てのリソースを最大限まで使えたら完璧なチューニング
• つまり
– CPU使用率100%
– メモリ使用率100%
– ディスクI/O使用率100%
– NW使用率100%
を同時に見対している状態
9
考え方の整理はこの本がおすすめ
Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved
解くべき問題の明確化
10
Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved
本当にMongoDBが遅いのか?
• 「画面の応答が遅い」「アプリの実行時間がながい」
→本当にMongoDBが遅いんですか?
• ミドルウェアのログから各レイヤでの処理時間を計測
– 大多数のケースで、これが整理できていない
11
ブラウザ Webアプリ MongoDB
t0
t1
t2
t3
t4
t5
t6
本当にココ
が遅いの
か?
Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved
MongoDBの何が遅いのか
• 何のクエリが遅いのか?
– 読み取り、書き込み、集計
– 可能であればクエリを特定する
• 何の指標が遅いのか?
– レスポンスタイムが遅い
• スロークエリログを見てクエリ応答時間をみる
• プロファイラを有効にしてクエリの情報を見る
– スループットが低い
• mongostatを見て、単位時間あたりの処理量をみる
• mongotopを見て、コレクションごとの処理量をみる
12
Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved
遅い箇所の調べ方
• スロークエリログ
– 設定ファイルで起動前に指定する
– デフォルトで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()
Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved
遅い箇所の調べ方
• 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
Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved
遅い箇所の調べ方
• MongoDB CloudManager(旧OpsManager, MMS)を使って
も良い
– あらかじめMongoDBに特化したメトリックがとられる
– 監視項目を設計しなくて良い
15
Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved
根本原因の特定
16
Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved
根本原因の特定
• 結論は2種類
– ボトルネックが有る
or
– ボトルネックが無い
• ボトルネックが有る
– CPU 1core張り付き、高ロードアベレージ→1.CPUボトルネック
– メモリ空き容量0、ディスクIO頻発→2.IOボトルネック
– ネットワーク流量 逼迫(80%超え) →3.NWボトルネック
• ボトルネックがない
– MongoDBに本気を出させることが出来ていない→4.処理の非効率
17
Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved
根本原因の特定
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
Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved
根本原因の特定
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
Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved
根本原因の特定
3.IOボトルネック
• 概要
– メモリ上にデータがなく、ディスクにデータを読みに行くことが頻発
すると、ディスクはメモリに対して100倍程度遅いため、全体として処
理速度が低下する。
– MongoDB(というかDB全般)では大半がこのケース
• チェック方法
– OSのiostatコマンドで、 avgqusz, await, %util が高い。 rMB/s、
wMB/sがいつもより多い。CPUのiowaitが多い
– キャッシュが溢れている
• MMAPv1の場合、mongostatのページフォルトが多い
• WiredTigerの場合、キャッシュへの読み込み累積値(bytes read into
cache)が物理メモリ量を超えて増え続けている
• 解消方法
– 次ページで説明
20
Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved
根本原因の特定
3.IOボトルネック - 解消方法
1. インデックス
– RDBと同じB-Treeでインデックスがあるので、同じ考え方でインデックスを設
計すれば良い
– 実行計画の見方
• db.mycol.find().explain() →実行はしないで計画を表示
• db.mycol.find().explain("executionStats") →実際に実行する
2. メモリキャッシュ
– メモリを駆使してIOボトルネックを解消するには
MongoDBのアーキテクチャの理解が必須
– ストレージエンジンによって全く違う
• MMAPv1 : メモリ管理をOSまかせ
• WiredTiger : MongoDBが買収した最先端のストレージ
– →後半でガッツリ説明
21
Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved
根本原因の特定
4. 処理の非効率
• 書き込みが遅い
– ロック開放待ちになっている(MMAP限定)
– バッチインサートしていない
– Write Concernの値が必要以上に大きい
– WiredTigerの場合は同時に実行できるクエリ数にそれぞれ128
の制限(Ticketsという)があり、それに引っかかっていないか
• db.serverStatus().wiredTiger.concurrentTransactions
• 読み込みが遅い
– フェッチが細かすぎる
– 同時実行
– 同時実行クエリ数制限
22
Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved
IOボトルネックの解消
MMAPv1の場合
23
Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved
読み込み時の動き(MMAP)
• 起動時に、mongodは、OSに対して、
データベースファイルをメモリにmapするように依頼する
– システムコールmmap()を実行
• 起動直後はメモリは空
24
doc1 doc3index doc2
ディスク
メモリ
mongodプロセス
OSが管理
ブロック
データベースファイル
mmap(
)
Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved
読み込み時の動き(MMAP)
• mongodがdoc1を読もうとすると
– mongodは、OSに対して、ブロックの取得を依頼
– OSは、メモリ上にないので、ディスクから読む(=遅い)
• ページフォルト発生
• doc1と関連するindexのブロックだけが読み込まれる
25
doc1 doc3index doc2
ディスク
メモリ
doc1
mongodプロセス
index
Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved
読み込み時の動き(MMAP)
• doc1をもう一度読む
– mogodは、OSに対して、ブロックの取得を依頼
– OSは、メモリにあるので、メモリから返す応答する(=速い)
26
doc1 doc3index doc2
ディスク
メモリ
doc1
mongodプロセス
index
Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved
読み込み時の動き(MMAP)
• doc2を読むと
– indexはメモリにあるが、doc2はメモリにないので、ディスク
から読む(遅い)
27
doc1 doc3index doc2
ディスク
メモリ
doc1
mongodプロセス
doc2index
Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved
読み込み時の動き(MMAP)
• doc3を読むと
– doc3はメモリにないので、ディスクから読む
– 空きがないので、最もアクセス頻度の低いブロックを追い出す(ス
ワップアウト)
28
doc1 doc3index doc2
ディスク
メモリ
mongodプロセス
index doc3
Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved
MMAPで、IOネックで、読み込みが遅いときの原因候補
• インデックス
– インデックスが使われていない
– インデックスが有効ではない
• フルスキャンの方が効率が良い
• hint()の利用を検討
• キャッシュ
– 起動直後でキャッシュが空
– ワーキングセット(インデックスと使うデータ)がメモリに対して大す
ぎる
– OSにメモリの空きがなく、mongodがメモリをもらえていない
– 射影してもメモリにはドキュメント全体がのるが、その動きを知らない
• db.mycol.find({},{"name":1}) としてもname以外のデータもメモリに
乗る
– ブロックサイズがドキュメントに対して大きすぎて無駄が多い
29
doc1 無駄
Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved
書き込み時の動き(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'
Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved
書き込み時の動き(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'
Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved
MMAPで、IOネックで、書き込みが遅いときの原因候補
• インデックス
– インデックスがある
• キャッシュ
– 更新するドキュメント・インデックスがメモリに無い
– ジャーナルとデータを同じディスクい書いている
– 全てのデータベースが同じディスクに書いている
– MongoDBのログをデータと同じディスクに書いている
– Write concertnで j:trueになっていてジャーナルの物理書き込みを待って
いる
– ドキュメントのサイズが大きくなり、物理移動が発生している
• 肥大化が起こると、そのコレクションでは、次からドキュメントサイズに余裕を
持って物理領域を取るようになる→Padding factorの増加
– データ移動が頻発し、データファイルがフラグメンテーションして、必要
以上にメモリを利用しなくてはならない
32
doc1 doc3index doc2
doc3index doc2 doc1'
doc1index doc2 doc3
Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved
IOボトルネックの解消
WiredTigerの場合
33
Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved
WiredTigerの基本
• WiredTigerとは
– MongoDB,Incが買収したストレージ
– MMAPv1を差し替えることができる
• MMAPv1との違い
– OS任せだったメモリキャッシュを、ある程度制御するようになっ
た
– 更新は、その場(in place)ではなく、新しいバージョンのドキュメ
ントを挿入して、ポインタを張り替えようになった(MVCC,CAS)
• ロックが無くなった(事実上ドキュメントレベルロックと同じ)
• データファイルのフラグメンテーションがなくなった
• データの肥大化による移動がなくなった
• 裏で、古いバージョンをマージする動作(eviction)をするようになった
• これらにより、複数スレッドでマルチコアを有効に使って、スルー
プットをあげられるようになった
– インデックスとデータが別ファイルになった
– データの圧縮ができるようになった(メモリ量は圧縮できない)
34
Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved
mongodプロセス
WiredTigerキャッシュ
WiredTigerの動き(たぶん正しい)
• 起動直後はWiredTigerキャッシュは空
35
doc1
doc
3index ディスク
メモリ
doc2
Readスレッド Writeスレッド
dirtyページ
cleanページ
on diskページ
root
Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved
mongodプロセス
WiredTigerキャッシュ
WiredTigerの動き(たぶん正しい)
• 読み込むとツリーが形成される
• ツリーのリーフはディスクのページ毎に読み込まれている
• 以下の例ではdoc1を読んでいるので、indexとdocが含まれるページがキャッシュにのる
36
doc1
doc
3index ディスク
メモリ
doc2
Readスレッド Writeスレッド
doc1index
root
dirtyページ
cleanページ
on diskページ
Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved
mongodプロセス
WiredTigerキャッシュ
WiredTigerの動き(たぶん正しい)
• さらにdoc2やdoc3を読むと、キャッシュにのる
37
doc1
doc
3index ディスク
メモリ
doc2
Readスレッド Writeスレッド
doc1index
root
doc
3
doc2 dirtyページ
cleanページ
on diskページ
Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved
mongodプロセス
WiredTigerキャッシュ
WiredTigerの動き(たぶん正しい)
• ここでトランザクションtx1でdoc1をdoc1'に更新しようとする
(説明を簡単にするため、index更新は図から省略)
– これは新しいツリーをつくる動きになる
• それとは別に、メモリ上のジャーナルに更新内容を書き込む
– 50ms毎にディスクにSnappyで圧縮されて永続化される
38
doc1
doc
3index ディスク
メモリ
doc2
Readスレッド Writeスレッド
doc1index
root
doc
3
doc2 doc1’
root(tx1)
dirtyページ
cleanページ
on diskページ
tx1
tx1
tdoc1→doc1'
ジャーナル
ジャーナル
doc1→doc1'
Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved
mongodプロセス
WiredTigerキャッシュ
WiredTigerの動き(たぶん正しい)
• tx1が終わる前に、doc1の読み込みトランザクションtx2が動き出
すと、古いドキュメントが見える
39
doc1
doc
3index ディスク
メモリ
doc2
Readスレッド Writeスレッド
doc1index
root
doc
3
doc2 doc1’
root(tx1)
dirtyページ
cleanページ
on diskページ
tx1
tx2
tx2
tx1
tdoc1→doc1'
doc1→doc1'
ジャーナル
Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved
mongodプロセス
WiredTigerキャッシュ
WiredTigerの動き(たぶん正しい)
• tx1がcommitした後に、tx3がdoc1を読みに行くと、
新しいdoc1' が見える
40
doc1
doc
3index ディスク
メモリ
doc2
Readスレッド Writeスレッド
doc1index
root
doc
3
doc2 doc1’
root(tx1)
dirtyページ
cleanページ
on diskページ
tx3
tx2
tx1
tx3
t
doc1→doc1'
ジャーナル
Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved
mongodプロセス
WiredTigerキャッシュ
WiredTigerの動き(たぶん正しい)
• 前回のチェックポイントから60秒経過するか、
ジャーナルが2GBを超えると、チェックポイントになる
• Evictionスレッドがcleanなページとdirtyなページをマージしてディス
クへ書き込む
41
doc1'
doc
3index ディスク
メモリ
doc2
Readスレッド Writeスレッド
doc1index
root
doc
3
doc2
Evictionスレッド
doc1’
root(tx1)
dirtyページ
cleanページ
on diskページ
doc1→doc1'
ジャーナル
Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved
mongodプロセス
WiredTigerキャッシュ
WiredTigerの動き(たぶん正しい)
• チェックポイントが終わると、古いツリーは消されて、
キャッシュとディスクが同期する
• ジャーナルは空になる
42
doc1'
doc
3index ディスク
メモリ
doc2
Readスレッド Writeスレッド
index
doc
3
doc2 doc1’
root(tx1)
dirtyページ
cleanページ
on diskページ
ジャーナル
(空)
Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved
WiredTigerで、IOネックで、書き込みが遅いときの原因候補
• インデックス
– インデックスがある
• キャッシュ
– 更新するドキュメント・インデックスがメモリに無い
– ジャーナルとデータを同じディスクい書いている
– 全てのデータベースが同じディスクに書いている
– MongoDBのログをデータと同じディスクに書いている
– Write concertnで j:trueになっていてジャーナルの物理書き込みを
待っている
– ドキュメントのサイズが大きくなり、物理移動が発生している
– データ移動が頻発し、データファイルがフラグメンテーションして、
必要以上にメモリを圧迫している
43
Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved
WiredTigerで、IOネックで、読み込みが遅いときの原因候補
• インデックス
– インデックスが使われていない
– インデックスが有効ではない
• キャッシュ
– 起動直後でキャッシュが空
– ワーキングセット(インデックスと使うデータ)がメモリに対して
大すぎる
• メモリ上は圧縮されないので注意!
– 射影してもメモリにはドキュメント全体がのるが、その動きを知ら
ない
– ブロックサイズがドキュメントに対して大きすぎて無駄が多い
– OSにメモリの空きがなく、mongodがメモリをもらえていない
– WiredTigerだからおそい。MMAPv1よりやることが多い。
– WiredTigerのキャッシュを割り当てすぎてファイルキャッシュに使
えない(次ページで詳細)
44
Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved
WiredTigerキャッシュにメモリを割り当てすぎることによるデメリット
– mongodそのものでOOMになる可能性がある
– リードが多い場合は、Wiredキャッシュよりも、データが圧縮されている
ファイルキャッシュに多くのドキュメントを載せたほうが効率が良い事がある
45
mongodプロセス
WiredTigerキャッシュ
ディスク
メモリ
mongodそのものがつかうメモリ
Aggregation, Sort, 等
OS OSのファイルシステムキャッシュ
doc1
doc1
doc1
圧縮
圧縮
非圧縮
mongodの実メモリ
量
設定できるのは
ココだけ
空きメモリから
自動的に確保
2017/2/20更新: 「MongoDBのファイルキャッシュ」は存在しないため図から削
除
Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved
参考にした資料
• ちょっと古い公式説明資料。だいたい同じスライド
– 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

More Related Content

What's hot

Mongo dbを知ろう
Mongo dbを知ろうMongo dbを知ろう
Mongo dbを知ろう
CROOZ, inc.
 

What's hot (20)

コンテナ未経験新人が学ぶコンテナ技術入門
コンテナ未経験新人が学ぶコンテナ技術入門コンテナ未経験新人が学ぶコンテナ技術入門
コンテナ未経験新人が学ぶコンテナ技術入門
 
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
 
Dockerfile を書くためのベストプラクティス解説編
Dockerfile を書くためのベストプラクティス解説編Dockerfile を書くためのベストプラクティス解説編
Dockerfile を書くためのベストプラクティス解説編
 
がっつりMongoDB事例紹介
がっつりMongoDB事例紹介がっつりMongoDB事例紹介
がっつりMongoDB事例紹介
 
ビッグデータ処理データベースの全体像と使い分け
ビッグデータ処理データベースの全体像と使い分けビッグデータ処理データベースの全体像と使い分け
ビッグデータ処理データベースの全体像と使い分け
 
Grafana LokiではじめるKubernetesロギングハンズオン(NTT Tech Conference #4 ハンズオン資料)
Grafana LokiではじめるKubernetesロギングハンズオン(NTT Tech Conference #4 ハンズオン資料)Grafana LokiではじめるKubernetesロギングハンズオン(NTT Tech Conference #4 ハンズオン資料)
Grafana LokiではじめるKubernetesロギングハンズオン(NTT Tech Conference #4 ハンズオン資料)
 
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
 
AWS Black Belt Online Seminar 2018 Amazon DynamoDB Advanced Design Pattern
AWS Black Belt Online Seminar 2018 Amazon DynamoDB Advanced Design PatternAWS Black Belt Online Seminar 2018 Amazon DynamoDB Advanced Design Pattern
AWS Black Belt Online Seminar 2018 Amazon DynamoDB Advanced Design Pattern
 
Docker Compose 徹底解説
Docker Compose 徹底解説Docker Compose 徹底解説
Docker Compose 徹底解説
 
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
 
Apache Avro vs Protocol Buffers
Apache Avro vs Protocol BuffersApache Avro vs Protocol Buffers
Apache Avro vs Protocol Buffers
 
マルチテナント化で知っておきたいデータベースのこと
マルチテナント化で知っておきたいデータベースのことマルチテナント化で知っておきたいデータベースのこと
マルチテナント化で知っておきたいデータベースのこと
 
MongoDBのアレをアレする
MongoDBのアレをアレするMongoDBのアレをアレする
MongoDBのアレをアレする
 
マイクロサービスバックエンドAPIのためのRESTとgRPC
マイクロサービスバックエンドAPIのためのRESTとgRPCマイクロサービスバックエンドAPIのためのRESTとgRPC
マイクロサービスバックエンドAPIのためのRESTとgRPC
 
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話
 
PostgreSQL 15 開発最新情報
PostgreSQL 15 開発最新情報PostgreSQL 15 開発最新情報
PostgreSQL 15 開発最新情報
 
YugabyteDBを使ってみよう(NewSQL/分散SQLデータベースよろず勉強会 #1 発表資料)
YugabyteDBを使ってみよう(NewSQL/分散SQLデータベースよろず勉強会 #1 発表資料)YugabyteDBを使ってみよう(NewSQL/分散SQLデータベースよろず勉強会 #1 発表資料)
YugabyteDBを使ってみよう(NewSQL/分散SQLデータベースよろず勉強会 #1 発表資料)
 
コンテナにおけるパフォーマンス調査でハマった話
コンテナにおけるパフォーマンス調査でハマった話コンテナにおけるパフォーマンス調査でハマった話
コンテナにおけるパフォーマンス調査でハマった話
 
Mongo dbを知ろう
Mongo dbを知ろうMongo dbを知ろう
Mongo dbを知ろう
 
分析指向データレイク実現の次の一手 ~Delta Lake、なにそれおいしいの?~(NTTデータ テクノロジーカンファレンス 2020 発表資料)
分析指向データレイク実現の次の一手 ~Delta Lake、なにそれおいしいの?~(NTTデータ テクノロジーカンファレンス 2020 発表資料)分析指向データレイク実現の次の一手 ~Delta Lake、なにそれおいしいの?~(NTTデータ テクノロジーカンファレンス 2020 発表資料)
分析指向データレイク実現の次の一手 ~Delta Lake、なにそれおいしいの?~(NTTデータ テクノロジーカンファレンス 2020 発表資料)
 

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

大規模化するピグライフを支えるインフラ ~MongoDBとChefについて~ (前編)
大規模化するピグライフを支えるインフラ ~MongoDBとChefについて~ (前編)大規模化するピグライフを支えるインフラ ~MongoDBとChefについて~ (前編)
大規模化するピグライフを支えるインフラ ~MongoDBとChefについて~ (前編)
Akihiro Kuwano
 
DB tech showcase: 噂のMongoDBその用途は?
DB tech showcase: 噂のMongoDBその用途は?DB tech showcase: 噂のMongoDBその用途は?
DB tech showcase: 噂のMongoDBその用途は?
Hiroaki Kubota
 
MongoDBを用いたソーシャルアプリのログ解析 〜解析基盤構築からフロントUIまで、MongoDBを最大限に活用する〜
MongoDBを用いたソーシャルアプリのログ解析 〜解析基盤構築からフロントUIまで、MongoDBを最大限に活用する〜MongoDBを用いたソーシャルアプリのログ解析 〜解析基盤構築からフロントUIまで、MongoDBを最大限に活用する〜
MongoDBを用いたソーシャルアプリのログ解析 〜解析基盤構築からフロントUIまで、MongoDBを最大限に活用する〜
Takahiro Inoue
 
泥臭い運用から、プログラマブルインフラ構築(に行きたい)
泥臭い運用から、プログラマブルインフラ構築(に行きたい) 泥臭い運用から、プログラマブルインフラ構築(に行きたい)
泥臭い運用から、プログラマブルインフラ構築(に行きたい)
Akihiro Kuwano
 
20120405 setsunaセミナー
20120405 setsunaセミナー20120405 setsunaセミナー
20120405 setsunaセミナー
Takahiro Iwase
 
Introduction to MongoDB
Introduction to MongoDBIntroduction to MongoDB
Introduction to MongoDB
moai kids
 
Linux/DB Tuning (DevSumi2010, Japanese)
Linux/DB Tuning (DevSumi2010, Japanese)Linux/DB Tuning (DevSumi2010, Japanese)
Linux/DB Tuning (DevSumi2010, Japanese)
Yoshinori Matsunobu
 

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

PHP開発者のためのNoSQL入門
PHP開発者のためのNoSQL入門PHP開発者のためのNoSQL入門
PHP開発者のためのNoSQL入門
 
大規模化するピグライフを支えるインフラ ~MongoDBとChefについて~ (前編)
大規模化するピグライフを支えるインフラ ~MongoDBとChefについて~ (前編)大規模化するピグライフを支えるインフラ ~MongoDBとChefについて~ (前編)
大規模化するピグライフを支えるインフラ ~MongoDBとChefについて~ (前編)
 
地方企業がソーシャルゲーム開発を成功させるための10のポイント
地方企業がソーシャルゲーム開発を成功させるための10のポイント地方企業がソーシャルゲーム開発を成功させるための10のポイント
地方企業がソーシャルゲーム開発を成功させるための10のポイント
 
使ってみた!ioMemoryで実現する噂のAtomic write!
使ってみた!ioMemoryで実現する噂のAtomic write!使ってみた!ioMemoryで実現する噂のAtomic write!
使ってみた!ioMemoryで実現する噂のAtomic write!
 
MongoDB勉強会資料
MongoDB勉強会資料MongoDB勉強会資料
MongoDB勉強会資料
 
シラサギハンズオン 東京
シラサギハンズオン 東京シラサギハンズオン 東京
シラサギハンズオン 東京
 
ビッグデータ処理データベースの全体像と使い分け - 2017年 Version -
ビッグデータ処理データベースの全体像と使い分け - 2017年 Version - ビッグデータ処理データベースの全体像と使い分け - 2017年 Version -
ビッグデータ処理データベースの全体像と使い分け - 2017年 Version -
 
DB tech showcase: 噂のMongoDBその用途は?
DB tech showcase: 噂のMongoDBその用途は?DB tech showcase: 噂のMongoDBその用途は?
DB tech showcase: 噂のMongoDBその用途は?
 
MongoDBを用いたソーシャルアプリのログ解析 〜解析基盤構築からフロントUIまで、MongoDBを最大限に活用する〜
MongoDBを用いたソーシャルアプリのログ解析 〜解析基盤構築からフロントUIまで、MongoDBを最大限に活用する〜MongoDBを用いたソーシャルアプリのログ解析 〜解析基盤構築からフロントUIまで、MongoDBを最大限に活用する〜
MongoDBを用いたソーシャルアプリのログ解析 〜解析基盤構築からフロントUIまで、MongoDBを最大限に活用する〜
 
大規模ソーシャルゲーム開発から学んだPHP&MySQL実践テクニック
大規模ソーシャルゲーム開発から学んだPHP&MySQL実践テクニック大規模ソーシャルゲーム開発から学んだPHP&MySQL実践テクニック
大規模ソーシャルゲーム開発から学んだPHP&MySQL実践テクニック
 
シラサギハンズオン 大阪
シラサギハンズオン 大阪シラサギハンズオン 大阪
シラサギハンズオン 大阪
 
泥臭い運用から、プログラマブルインフラ構築(に行きたい)
泥臭い運用から、プログラマブルインフラ構築(に行きたい) 泥臭い運用から、プログラマブルインフラ構築(に行きたい)
泥臭い運用から、プログラマブルインフラ構築(に行きたい)
 
既存システムへの新技術活用法 ~fluntd/MongoDB~
既存システムへの新技術活用法 ~fluntd/MongoDB~既存システムへの新技術活用法 ~fluntd/MongoDB~
既存システムへの新技術活用法 ~fluntd/MongoDB~
 
20120405 setsunaセミナー
20120405 setsunaセミナー20120405 setsunaセミナー
20120405 setsunaセミナー
 
Introduction to MongoDB
Introduction to MongoDBIntroduction to MongoDB
Introduction to MongoDB
 
Linux/DB Tuning (DevSumi2010, Japanese)
Linux/DB Tuning (DevSumi2010, Japanese)Linux/DB Tuning (DevSumi2010, Japanese)
Linux/DB Tuning (DevSumi2010, Japanese)
 
スマートフォン×Cassandraによるハイパフォーマンス基盤の構築事例
スマートフォン×Cassandraによるハイパフォーマンス基盤の構築事例スマートフォン×Cassandraによるハイパフォーマンス基盤の構築事例
スマートフォン×Cassandraによるハイパフォーマンス基盤の構築事例
 
ビックデータ処理技術の全体像とリクルートでの使い分け
ビックデータ処理技術の全体像とリクルートでの使い分けビックデータ処理技術の全体像とリクルートでの使い分け
ビックデータ処理技術の全体像とリクルートでの使い分け
 
ioMemoryとAtomic Writeによるデータベース高速化
ioMemoryとAtomic Writeによるデータベース高速化ioMemoryとAtomic Writeによるデータベース高速化
ioMemoryとAtomic Writeによるデータベース高速化
 
zozotown real time linkage infrastructure
zozotown real time linkage infrastructurezozotown real time linkage infrastructure
zozotown real time linkage infrastructure
 

More from Tetsutaro Watanabe

More from Tetsutaro Watanabe (18)

データサイエンティスト向け性能問題対応の基礎
データサイエンティスト向け性能問題対応の基礎データサイエンティスト向け性能問題対応の基礎
データサイエンティスト向け性能問題対応の基礎
 
MLOpsはバズワード
MLOpsはバズワードMLOpsはバズワード
MLOpsはバズワード
 
ドライブレコーダの動画を使った道路情報の自動差分抽出
ドライブレコーダの動画を使った道路情報の自動差分抽出ドライブレコーダの動画を使った道路情報の自動差分抽出
ドライブレコーダの動画を使った道路情報の自動差分抽出
 
IoTデバイスデータ収集の難しい点
IoTデバイスデータ収集の難しい点IoTデバイスデータ収集の難しい点
IoTデバイスデータ収集の難しい点
 
ドライブレコーダの画像認識による道路情報の自動差分抽出
ドライブレコーダの画像認識による道路情報の自動差分抽出ドライブレコーダの画像認識による道路情報の自動差分抽出
ドライブレコーダの画像認識による道路情報の自動差分抽出
 
先駆者に学ぶ MLOpsの実際
先駆者に学ぶ MLOpsの実際先駆者に学ぶ MLOpsの実際
先駆者に学ぶ MLOpsの実際
 
データ収集の基本と「JapanTaxi」アプリにおける実践例
データ収集の基本と「JapanTaxi」アプリにおける実践例データ収集の基本と「JapanTaxi」アプリにおける実践例
データ収集の基本と「JapanTaxi」アプリにおける実践例
 
ML Ops NYC 19 & Strata Data Conference 2019 NewYork 注目セッションまとめ
ML Ops NYC 19 & Strata Data Conference 2019 NewYork 注目セッションまとめML Ops NYC 19 & Strata Data Conference 2019 NewYork 注目セッションまとめ
ML Ops NYC 19 & Strata Data Conference 2019 NewYork 注目セッションまとめ
 
タクシードライブレコーダーの動画処理MLパイプラインにkubernetesを使ってみた
タクシードライブレコーダーの動画処理MLパイプラインにkubernetesを使ってみたタクシードライブレコーダーの動画処理MLパイプラインにkubernetesを使ってみた
タクシードライブレコーダーの動画処理MLパイプラインにkubernetesを使ってみた
 
JapanTaxiにおけるSagemaker+αによる機械学習アプリケーションの本番運用
JapanTaxiにおけるSagemaker+αによる機械学習アプリケーションの本番運用JapanTaxiにおけるSagemaker+αによる機械学習アプリケーションの本番運用
JapanTaxiにおけるSagemaker+αによる機械学習アプリケーションの本番運用
 
JapanTaxiにおけるML Ops 〜機械学習の開発運用プロセス〜
JapanTaxiにおけるML Ops 〜機械学習の開発運用プロセス〜JapanTaxiにおけるML Ops 〜機械学習の開発運用プロセス〜
JapanTaxiにおけるML Ops 〜機械学習の開発運用プロセス〜
 
ビッグデータ処理データベースの全体像と使い分け
2018年version
ビッグデータ処理データベースの全体像と使い分け
2018年versionビッグデータ処理データベースの全体像と使い分け
2018年version
ビッグデータ処理データベースの全体像と使い分け
2018年version
 
Google Cloud Next '18 Recap/報告会 機械学習関連
Google Cloud Next '18 Recap/報告会 機械学習関連Google Cloud Next '18 Recap/報告会 機械学習関連
Google Cloud Next '18 Recap/報告会 機械学習関連
 
巨大なサービスと膨大なデータを支えるプラットフォーム

巨大なサービスと膨大なデータを支えるプラットフォーム
巨大なサービスと膨大なデータを支えるプラットフォーム

巨大なサービスと膨大なデータを支えるプラットフォーム

 
リクルートを支える横断データ基盤と機械学習の適用事例
リクルートを支える横断データ基盤と機械学習の適用事例リクルートを支える横断データ基盤と機械学習の適用事例
リクルートを支える横断データ基盤と機械学習の適用事例
 
リクルートテクノロジーズ における EMR の活用とコスト圧縮方法
リクルートテクノロジーズ における EMR の活用とコスト圧縮方法リクルートテクノロジーズ における EMR の活用とコスト圧縮方法
リクルートテクノロジーズ における EMR の活用とコスト圧縮方法
 
MongoDB3.2の紹介
MongoDB3.2の紹介MongoDB3.2の紹介
MongoDB3.2の紹介
 
MongoDB World 2014に行ってきた!
MongoDB World 2014に行ってきた!MongoDB World 2014に行ってきた!
MongoDB World 2014に行ってきた!
 

Recently uploaded

2024年5月25日Serverless Meetup大阪 アプリケーションをどこで動かすべきなのか.pptx
2024年5月25日Serverless Meetup大阪 アプリケーションをどこで動かすべきなのか.pptx2024年5月25日Serverless Meetup大阪 アプリケーションをどこで動かすべきなのか.pptx
2024年5月25日Serverless Meetup大阪 アプリケーションをどこで動かすべきなのか.pptx
ssuserbefd24
 
研究紹介スライド: オフライン強化学習に基づくロボティックスワームの制御器の設計
研究紹介スライド: オフライン強化学習に基づくロボティックスワームの制御器の設計研究紹介スライド: オフライン強化学習に基づくロボティックスワームの制御器の設計
研究紹介スライド: オフライン強化学習に基づくロボティックスワームの制御器の設計
atsushi061452
 

Recently uploaded (12)

論文紹介:Deep Occlusion-Aware Instance Segmentation With Overlapping BiLayers
論文紹介:Deep Occlusion-Aware Instance Segmentation With Overlapping BiLayers論文紹介:Deep Occlusion-Aware Instance Segmentation With Overlapping BiLayers
論文紹介:Deep Occlusion-Aware Instance Segmentation With Overlapping BiLayers
 
情報を表現するときのポイント
情報を表現するときのポイント情報を表現するときのポイント
情報を表現するときのポイント
 
2024年5月25日Serverless Meetup大阪 アプリケーションをどこで動かすべきなのか.pptx
2024年5月25日Serverless Meetup大阪 アプリケーションをどこで動かすべきなのか.pptx2024年5月25日Serverless Meetup大阪 アプリケーションをどこで動かすべきなのか.pptx
2024年5月25日Serverless Meetup大阪 アプリケーションをどこで動かすべきなのか.pptx
 
クラウド時代におけるSREとUPWARDの取組ーUPWARD株式会社 CTO門畑
クラウド時代におけるSREとUPWARDの取組ーUPWARD株式会社 CTO門畑クラウド時代におけるSREとUPWARDの取組ーUPWARD株式会社 CTO門畑
クラウド時代におけるSREとUPWARDの取組ーUPWARD株式会社 CTO門畑
 
Amazon Cognitoで実装するパスキー (Security-JAWS【第33回】 勉強会)
Amazon Cognitoで実装するパスキー (Security-JAWS【第33回】 勉強会)Amazon Cognitoで実装するパスキー (Security-JAWS【第33回】 勉強会)
Amazon Cognitoで実装するパスキー (Security-JAWS【第33回】 勉強会)
 
論文紹介:ViTPose: Simple Vision Transformer Baselines for Human Pose Estimation
論文紹介:ViTPose: Simple Vision Transformer Baselines for Human Pose Estimation論文紹介:ViTPose: Simple Vision Transformer Baselines for Human Pose Estimation
論文紹介:ViTPose: Simple Vision Transformer Baselines for Human Pose Estimation
 
5/22 第23回 Customer系エンジニア座談会のスライド 公開用 西口瑛一
5/22 第23回 Customer系エンジニア座談会のスライド 公開用 西口瑛一5/22 第23回 Customer系エンジニア座談会のスライド 公開用 西口瑛一
5/22 第23回 Customer系エンジニア座談会のスライド 公開用 西口瑛一
 
20240523_IoTLT_vol111_kitazaki_v1___.pdf
20240523_IoTLT_vol111_kitazaki_v1___.pdf20240523_IoTLT_vol111_kitazaki_v1___.pdf
20240523_IoTLT_vol111_kitazaki_v1___.pdf
 
研究紹介スライド: オフライン強化学習に基づくロボティックスワームの制御器の設計
研究紹介スライド: オフライン強化学習に基づくロボティックスワームの制御器の設計研究紹介スライド: オフライン強化学習に基づくロボティックスワームの制御器の設計
研究紹介スライド: オフライン強化学習に基づくロボティックスワームの制御器の設計
 
部内勉強会(IT用語ざっくり学習) 実施日:2024年5月17日(金) 対象者:営業部社員
部内勉強会(IT用語ざっくり学習) 実施日:2024年5月17日(金) 対象者:営業部社員部内勉強会(IT用語ざっくり学習) 実施日:2024年5月17日(金) 対象者:営業部社員
部内勉強会(IT用語ざっくり学習) 実施日:2024年5月17日(金) 対象者:営業部社員
 
ロボットマニピュレーションの作業・動作計画 / rosjp_planning_for_robotic_manipulation_20240521
ロボットマニピュレーションの作業・動作計画 / rosjp_planning_for_robotic_manipulation_20240521ロボットマニピュレーションの作業・動作計画 / rosjp_planning_for_robotic_manipulation_20240521
ロボットマニピュレーションの作業・動作計画 / rosjp_planning_for_robotic_manipulation_20240521
 
Intranet Development v1.0 (TSG LIVE! 12 LT )
Intranet Development v1.0 (TSG LIVE! 12 LT )Intranet Development v1.0 (TSG LIVE! 12 LT )
Intranet Development v1.0 (TSG LIVE! 12 LT )
 

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

  • 1. Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved MongoDBが遅いときの切り分け方法 コンサルタント 渡部 徹太郎 1
  • 2. Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved 自己紹介 2 {"ID" :"fetaro" "名前":"渡部 徹太郎" "研究":"東京工業大学でデータベースと情報検索の研究 (@日本データベース学会)" "仕事":{前職:["証券会社のオンライントレードシステムのWeb基盤", "オープンソースなら何でも。主にMongoDB,NoSQL"], 現職:["大手Web企業の横断分析基盤,Exadata,Hortonworks,EMR"] 副業:["MongoDBコンサルタント" ]} "エディタ":"emacs派", "趣味": ["自宅サーバ","麻雀"] }
  • 3. Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved はじめに MongoDBは速い? • MongoDBはNoSQLだからRDBより速い? • シャーディングすれば単体構成より速い? 3
  • 4. Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved はじめに MongoDBは速い?→ケースに依る • MongoDBはNoSQLだからRDBより速い わけではない – RDBとは提供している機能が違う • トランザクション、JOIN、副問合せ等のRDBで遅くなりがちな 複雑なクエリはMongoDBは提供していない • データモデルが違う、保証する整合性が違う – シンプルなクエリであればRDBとMongoDBでそれほど差はな い • MongoDBはオーバーヘッドが少ない分速いが • 結局はディスクIOをどれだけ減らせるか • シャーディングすれば単体構成より速い とは限らない – ボトルネックが分散するようにシャーディングを組まないとい けない – データだけ分散しても駄目。クエリの分散まで考える必要あり – クエリが分散してもボトルネックが解消しないと駄目。 • 例)ネットワークネックならばIOが減っても意味なし 4
  • 5. Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved はじめに MongoDBを速くしたければRDBを勉強すべき • MongoDBだから特別なことはほとんどない • MongoDBはRDBに似ている – CassandraやDynamoDB 等はRDBと大きく違う • 8割はRDBのパフォーマンスチューニングの知識でカバーで きる – インデックス、クエリ最適化、キャッシュ、データ圧縮、WAL、 リードレプリカ、パーティショニング • 残り2割はMongoDB特有 – データ構造(JSON)が性能に与える影響 – シャーディング 今回の発表は、RDBにも通用する一般的な話が多いです 5
  • 6. Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved アジェンダ • 性能問題との向き合い方 • 解くべき問題の明確化 • 根本原因の特定 • IOボトルネックの解消 – MMAPv1の場合 – WiredTigerの場合 6
  • 7. Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved 性能問題との向き合い方 7
  • 8. Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved 性能問題を考える場合の思考順序 1. 解くべき問題の明確化 – 本当にMongoDBが遅いのか? • アプリやネットワークに問題はないか – どのクエリが遅いのか? • 読み込み, 書き込み, 集計 – 何を改善したいのか(性能要件の明確化) • レスポンスタイム,スループット 2. 根本原因の特定 – リソースが枯渇しているのか? • CPU, メモリ/ディスク, NW帯域 – 非効率な処理をしていないか? • ロック開放待ち、フェッチ、NWラウンドトリップ 3. 根本原因の解消 – リソース枯渇の場合 1. 単体構成の性能を最大限まで上げる→ 8割これでいける! 2. リードレプリカ→おまけ 3. シャーディング→最後の手段 – 処理が非効率の場合 • アプリを見直す 8
  • 9. Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved 性能問題調査でよくある間違い • よくある勘違い – CPU使用率が高すぎることが原因だ! • →いいことです – メモリ使用率が高すぎることが原因だ! • →溢れてIOが発生していなければ、いいことです • 全てのリソースを最大限まで使えたら完璧なチューニング • つまり – CPU使用率100% – メモリ使用率100% – ディスクI/O使用率100% – NW使用率100% を同時に見対している状態 9 考え方の整理はこの本がおすすめ
  • 10. Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved 解くべき問題の明確化 10
  • 11. Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved 本当にMongoDBが遅いのか? • 「画面の応答が遅い」「アプリの実行時間がながい」 →本当にMongoDBが遅いんですか? • ミドルウェアのログから各レイヤでの処理時間を計測 – 大多数のケースで、これが整理できていない 11 ブラウザ Webアプリ MongoDB t0 t1 t2 t3 t4 t5 t6 本当にココ が遅いの か?
  • 12. Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved MongoDBの何が遅いのか • 何のクエリが遅いのか? – 読み取り、書き込み、集計 – 可能であればクエリを特定する • 何の指標が遅いのか? – レスポンスタイムが遅い • スロークエリログを見てクエリ応答時間をみる • プロファイラを有効にしてクエリの情報を見る – スループットが低い • mongostatを見て、単位時間あたりの処理量をみる • mongotopを見て、コレクションごとの処理量をみる 12
  • 13. Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved 遅い箇所の調べ方 • スロークエリログ – 設定ファイルで起動前に指定する – デフォルトで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()
  • 14. Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved 遅い箇所の調べ方 • 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
  • 15. Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved 遅い箇所の調べ方 • MongoDB CloudManager(旧OpsManager, MMS)を使って も良い – あらかじめMongoDBに特化したメトリックがとられる – 監視項目を設計しなくて良い 15
  • 16. Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved 根本原因の特定 16
  • 17. Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved 根本原因の特定 • 結論は2種類 – ボトルネックが有る or – ボトルネックが無い • ボトルネックが有る – CPU 1core張り付き、高ロードアベレージ→1.CPUボトルネック – メモリ空き容量0、ディスクIO頻発→2.IOボトルネック – ネットワーク流量 逼迫(80%超え) →3.NWボトルネック • ボトルネックがない – MongoDBに本気を出させることが出来ていない→4.処理の非効率 17
  • 18. Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved 根本原因の特定 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
  • 19. Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved 根本原因の特定 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
  • 20. Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved 根本原因の特定 3.IOボトルネック • 概要 – メモリ上にデータがなく、ディスクにデータを読みに行くことが頻発 すると、ディスクはメモリに対して100倍程度遅いため、全体として処 理速度が低下する。 – MongoDB(というかDB全般)では大半がこのケース • チェック方法 – OSのiostatコマンドで、 avgqusz, await, %util が高い。 rMB/s、 wMB/sがいつもより多い。CPUのiowaitが多い – キャッシュが溢れている • MMAPv1の場合、mongostatのページフォルトが多い • WiredTigerの場合、キャッシュへの読み込み累積値(bytes read into cache)が物理メモリ量を超えて増え続けている • 解消方法 – 次ページで説明 20
  • 21. Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved 根本原因の特定 3.IOボトルネック - 解消方法 1. インデックス – RDBと同じB-Treeでインデックスがあるので、同じ考え方でインデックスを設 計すれば良い – 実行計画の見方 • db.mycol.find().explain() →実行はしないで計画を表示 • db.mycol.find().explain("executionStats") →実際に実行する 2. メモリキャッシュ – メモリを駆使してIOボトルネックを解消するには MongoDBのアーキテクチャの理解が必須 – ストレージエンジンによって全く違う • MMAPv1 : メモリ管理をOSまかせ • WiredTiger : MongoDBが買収した最先端のストレージ – →後半でガッツリ説明 21
  • 22. Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved 根本原因の特定 4. 処理の非効率 • 書き込みが遅い – ロック開放待ちになっている(MMAP限定) – バッチインサートしていない – Write Concernの値が必要以上に大きい – WiredTigerの場合は同時に実行できるクエリ数にそれぞれ128 の制限(Ticketsという)があり、それに引っかかっていないか • db.serverStatus().wiredTiger.concurrentTransactions • 読み込みが遅い – フェッチが細かすぎる – 同時実行 – 同時実行クエリ数制限 22
  • 23. Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved IOボトルネックの解消 MMAPv1の場合 23
  • 24. Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved 読み込み時の動き(MMAP) • 起動時に、mongodは、OSに対して、 データベースファイルをメモリにmapするように依頼する – システムコールmmap()を実行 • 起動直後はメモリは空 24 doc1 doc3index doc2 ディスク メモリ mongodプロセス OSが管理 ブロック データベースファイル mmap( )
  • 25. Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved 読み込み時の動き(MMAP) • mongodがdoc1を読もうとすると – mongodは、OSに対して、ブロックの取得を依頼 – OSは、メモリ上にないので、ディスクから読む(=遅い) • ページフォルト発生 • doc1と関連するindexのブロックだけが読み込まれる 25 doc1 doc3index doc2 ディスク メモリ doc1 mongodプロセス index
  • 26. Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved 読み込み時の動き(MMAP) • doc1をもう一度読む – mogodは、OSに対して、ブロックの取得を依頼 – OSは、メモリにあるので、メモリから返す応答する(=速い) 26 doc1 doc3index doc2 ディスク メモリ doc1 mongodプロセス index
  • 27. Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved 読み込み時の動き(MMAP) • doc2を読むと – indexはメモリにあるが、doc2はメモリにないので、ディスク から読む(遅い) 27 doc1 doc3index doc2 ディスク メモリ doc1 mongodプロセス doc2index
  • 28. Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved 読み込み時の動き(MMAP) • doc3を読むと – doc3はメモリにないので、ディスクから読む – 空きがないので、最もアクセス頻度の低いブロックを追い出す(ス ワップアウト) 28 doc1 doc3index doc2 ディスク メモリ mongodプロセス index doc3
  • 29. Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved MMAPで、IOネックで、読み込みが遅いときの原因候補 • インデックス – インデックスが使われていない – インデックスが有効ではない • フルスキャンの方が効率が良い • hint()の利用を検討 • キャッシュ – 起動直後でキャッシュが空 – ワーキングセット(インデックスと使うデータ)がメモリに対して大す ぎる – OSにメモリの空きがなく、mongodがメモリをもらえていない – 射影してもメモリにはドキュメント全体がのるが、その動きを知らない • db.mycol.find({},{"name":1}) としてもname以外のデータもメモリに 乗る – ブロックサイズがドキュメントに対して大きすぎて無駄が多い 29 doc1 無駄
  • 30. Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved 書き込み時の動き(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'
  • 31. Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved 書き込み時の動き(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'
  • 32. Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved MMAPで、IOネックで、書き込みが遅いときの原因候補 • インデックス – インデックスがある • キャッシュ – 更新するドキュメント・インデックスがメモリに無い – ジャーナルとデータを同じディスクい書いている – 全てのデータベースが同じディスクに書いている – MongoDBのログをデータと同じディスクに書いている – Write concertnで j:trueになっていてジャーナルの物理書き込みを待って いる – ドキュメントのサイズが大きくなり、物理移動が発生している • 肥大化が起こると、そのコレクションでは、次からドキュメントサイズに余裕を 持って物理領域を取るようになる→Padding factorの増加 – データ移動が頻発し、データファイルがフラグメンテーションして、必要 以上にメモリを利用しなくてはならない 32 doc1 doc3index doc2 doc3index doc2 doc1' doc1index doc2 doc3
  • 33. Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved IOボトルネックの解消 WiredTigerの場合 33
  • 34. Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved WiredTigerの基本 • WiredTigerとは – MongoDB,Incが買収したストレージ – MMAPv1を差し替えることができる • MMAPv1との違い – OS任せだったメモリキャッシュを、ある程度制御するようになっ た – 更新は、その場(in place)ではなく、新しいバージョンのドキュメ ントを挿入して、ポインタを張り替えようになった(MVCC,CAS) • ロックが無くなった(事実上ドキュメントレベルロックと同じ) • データファイルのフラグメンテーションがなくなった • データの肥大化による移動がなくなった • 裏で、古いバージョンをマージする動作(eviction)をするようになった • これらにより、複数スレッドでマルチコアを有効に使って、スルー プットをあげられるようになった – インデックスとデータが別ファイルになった – データの圧縮ができるようになった(メモリ量は圧縮できない) 34
  • 35. Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved mongodプロセス WiredTigerキャッシュ WiredTigerの動き(たぶん正しい) • 起動直後はWiredTigerキャッシュは空 35 doc1 doc 3index ディスク メモリ doc2 Readスレッド Writeスレッド dirtyページ cleanページ on diskページ root
  • 36. Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved mongodプロセス WiredTigerキャッシュ WiredTigerの動き(たぶん正しい) • 読み込むとツリーが形成される • ツリーのリーフはディスクのページ毎に読み込まれている • 以下の例ではdoc1を読んでいるので、indexとdocが含まれるページがキャッシュにのる 36 doc1 doc 3index ディスク メモリ doc2 Readスレッド Writeスレッド doc1index root dirtyページ cleanページ on diskページ
  • 37. Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved mongodプロセス WiredTigerキャッシュ WiredTigerの動き(たぶん正しい) • さらにdoc2やdoc3を読むと、キャッシュにのる 37 doc1 doc 3index ディスク メモリ doc2 Readスレッド Writeスレッド doc1index root doc 3 doc2 dirtyページ cleanページ on diskページ
  • 38. Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved mongodプロセス WiredTigerキャッシュ WiredTigerの動き(たぶん正しい) • ここでトランザクションtx1でdoc1をdoc1'に更新しようとする (説明を簡単にするため、index更新は図から省略) – これは新しいツリーをつくる動きになる • それとは別に、メモリ上のジャーナルに更新内容を書き込む – 50ms毎にディスクにSnappyで圧縮されて永続化される 38 doc1 doc 3index ディスク メモリ doc2 Readスレッド Writeスレッド doc1index root doc 3 doc2 doc1’ root(tx1) dirtyページ cleanページ on diskページ tx1 tx1 tdoc1→doc1' ジャーナル ジャーナル doc1→doc1'
  • 39. Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved mongodプロセス WiredTigerキャッシュ WiredTigerの動き(たぶん正しい) • tx1が終わる前に、doc1の読み込みトランザクションtx2が動き出 すと、古いドキュメントが見える 39 doc1 doc 3index ディスク メモリ doc2 Readスレッド Writeスレッド doc1index root doc 3 doc2 doc1’ root(tx1) dirtyページ cleanページ on diskページ tx1 tx2 tx2 tx1 tdoc1→doc1' doc1→doc1' ジャーナル
  • 40. Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved mongodプロセス WiredTigerキャッシュ WiredTigerの動き(たぶん正しい) • tx1がcommitした後に、tx3がdoc1を読みに行くと、 新しいdoc1' が見える 40 doc1 doc 3index ディスク メモリ doc2 Readスレッド Writeスレッド doc1index root doc 3 doc2 doc1’ root(tx1) dirtyページ cleanページ on diskページ tx3 tx2 tx1 tx3 t doc1→doc1' ジャーナル
  • 41. Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved mongodプロセス WiredTigerキャッシュ WiredTigerの動き(たぶん正しい) • 前回のチェックポイントから60秒経過するか、 ジャーナルが2GBを超えると、チェックポイントになる • Evictionスレッドがcleanなページとdirtyなページをマージしてディス クへ書き込む 41 doc1' doc 3index ディスク メモリ doc2 Readスレッド Writeスレッド doc1index root doc 3 doc2 Evictionスレッド doc1’ root(tx1) dirtyページ cleanページ on diskページ doc1→doc1' ジャーナル
  • 42. Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved mongodプロセス WiredTigerキャッシュ WiredTigerの動き(たぶん正しい) • チェックポイントが終わると、古いツリーは消されて、 キャッシュとディスクが同期する • ジャーナルは空になる 42 doc1' doc 3index ディスク メモリ doc2 Readスレッド Writeスレッド index doc 3 doc2 doc1’ root(tx1) dirtyページ cleanページ on diskページ ジャーナル (空)
  • 43. Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved WiredTigerで、IOネックで、書き込みが遅いときの原因候補 • インデックス – インデックスがある • キャッシュ – 更新するドキュメント・インデックスがメモリに無い – ジャーナルとデータを同じディスクい書いている – 全てのデータベースが同じディスクに書いている – MongoDBのログをデータと同じディスクに書いている – Write concertnで j:trueになっていてジャーナルの物理書き込みを 待っている – ドキュメントのサイズが大きくなり、物理移動が発生している – データ移動が頻発し、データファイルがフラグメンテーションして、 必要以上にメモリを圧迫している 43
  • 44. Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved WiredTigerで、IOネックで、読み込みが遅いときの原因候補 • インデックス – インデックスが使われていない – インデックスが有効ではない • キャッシュ – 起動直後でキャッシュが空 – ワーキングセット(インデックスと使うデータ)がメモリに対して 大すぎる • メモリ上は圧縮されないので注意! – 射影してもメモリにはドキュメント全体がのるが、その動きを知ら ない – ブロックサイズがドキュメントに対して大きすぎて無駄が多い – OSにメモリの空きがなく、mongodがメモリをもらえていない – WiredTigerだからおそい。MMAPv1よりやることが多い。 – WiredTigerのキャッシュを割り当てすぎてファイルキャッシュに使 えない(次ページで詳細) 44
  • 45. Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved WiredTigerキャッシュにメモリを割り当てすぎることによるデメリット – mongodそのものでOOMになる可能性がある – リードが多い場合は、Wiredキャッシュよりも、データが圧縮されている ファイルキャッシュに多くのドキュメントを載せたほうが効率が良い事がある 45 mongodプロセス WiredTigerキャッシュ ディスク メモリ mongodそのものがつかうメモリ Aggregation, Sort, 等 OS OSのファイルシステムキャッシュ doc1 doc1 doc1 圧縮 圧縮 非圧縮 mongodの実メモリ 量 設定できるのは ココだけ 空きメモリから 自動的に確保 2017/2/20更新: 「MongoDBのファイルキャッシュ」は存在しないため図から削 除
  • 46. Copyright ⓒ2016 CREATIONLINE, INC. All Rights Reserved 参考にした資料 • ちょっと古い公式説明資料。だいたい同じスライド – 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