More Related Content
Similar to CyberAgentにおけるMongoDB
Similar to CyberAgentにおけるMongoDB (20)
More from Akihiro Kuwano (20)
CyberAgentにおけるMongoDB
- 3. 自己紹介
n 桑野章弘
l サイバーエージェント
l Ameba を運営しています。
l ピグソーシャルゲームの運用/構築を担当
l Twitter
l @kuwa_tw
l Blog
l http://d.hatena.ne.jp/akuwano/
13年12月12日木曜日
- 59. n データ肥大
l 運用していくに連れてデータの肥大化する
l 定期的なデータのコンパクションが必要です
l repairコマンドは、データ容量と同容量のスペース
を利用するので注意
l データ容量が小容量かつ、一時的にMongoDBを止
められる場合、データdrop→データresoreの方が
簡単です。
l RS組んでいるならローリングコンパクション
13年12月12日木曜日
- 64. n MongoDBに使用するハードウェア
l DISK
l こちらも書き込み、読み込みが早いに越したことは無い
l 今までは、SAS * 4 RAID10 -> SSD * 2 RAID0
l 現在はSSDはSASの3倍のiops
l FileSystemはxfs or ext4
- 高速なfallocate()がサポートが必要
13年12月12日木曜日
- 65. n MongoDBに使用するハードウェア
l DISK
l ioDriveでの検証は、現状では8000opsを超えた位で
ReplicaSetsのoplogの転送が止まる事を確認していた
l が バージョン2.4ではこの現象はない=ioDrive 等を上手く
活用することでサーバ台数を減らすことができる
13年12月12日木曜日
- 67. n バックアップ
l mongodump
l mongosに対してmongodump実行するのはバックアッ
プとしては一番簡単
- 稼働中ではポイントイン・タイムバックアップではない
l mongodumpはmongodが起動していなくてもデータフ
ァイルに直接かけてBSONファイルを取得できるので、これ
を利用してポイントイン・タイムのバックアップを実装して
います
13年12月12日木曜日
- 68. n バックアップ
l 稼働中にスナップショットバックアップを取得
l RSメンバとしてarbiterとnovoteのプロセスを起動
l 1,mongos経由でAutoBalancingをOff
l 2,各レプリカセットのnovoteプロセスをダウン
l 3,各mongodからmongodumpでデータ取得
l 4 , mongos経由でAutoBalancingをOn
l 5 ,各Dumpデータの収集
l
13年12月12日木曜日
- 74. n Index
l indexが効いているかはexplain()で確認
l できるだけPK=_id で検索する実装にする
replSetTest1001:PRIMARY> db.User.find({'Field01': 'test'}).explain()
{
"cursor" : "BtreeCursor testIndex_1",
"nscanned" : 1,
"nscannedObjects" : 1,
"n" : 1,
"millis" : 7,
"nYields" : 0,
"nChunkSkips" : 0,
"isMultiKey" : false,
"indexOnly" : false,
13年12月12日木曜日
- 75. n Index
l 詳しいオプティマイザの実行結果が欲しい場合
は .explain(true)
replSetTest1001:PRIMARY> db.User.find({'_id': 'test'}).explain(true)
"allPlans" : [
{
"cursor" : "BtreeCursor _id_",
"n" : 1,
"nscannedObjects" : 1,
"nscanned" : 1,
"indexBounds" : {
"start" : {
"_id" : "test"
},
13年12月12日木曜日
- 79. n 運用効率化
l どうしても台数が多くなる傾向にあります。
l そのため「標準のコマンドだと表示が多すぎて見づら
い」「今のマスターの一覧が簡単に出したい」等の不
満がでます。
l これらはスクリプト作成等で対応しています、このあ
たりもJSONで各種データを取ってこれるために管理
ツールなどは作りやすいです。
13年12月12日木曜日
- 80. n 運用効率化 :運用スクリプトの内容
l ロックタイムの取得
l シャードに入っているmongod一覧のリスト出力
l レプリカセットのマスター検索
l レプリカセットのpriority検索
l printShardingStatusの整形
l レプリカセット一括作成/設定変更(現在のRSに
Delayホスト追加するなど)
13年12月12日木曜日
- 83. n mongostat
l クエリや、プロセスの現状を確認するコマンド
$ ./mongostat --host 192.168.8.41:27018,192.168.8.62:27018
insert query update delete getmore command flushes mapped
vsize res faults locked % idx miss %
qr¦qw ar¦aw netIn netOut conn
set repl
time
192.168.8.41:27018
0 361 132
0
209
437
0 36.1g 76.2g
14.3g
1
2.2
0
0¦0
2¦0 85k 698k 3056 RSTest1001 M
11:16:57
192.168.8.62:27018
0 384 164
0
245
480
0 30.1g 63.9g
15.6g
0
2
0
0¦0
2¦0 96k 652k 2587 RSTest1002 M
11:16:57
13年12月12日木曜日
- 84. n mongostat - 見るべき項目
l faults - 1秒当りのページフォールト数
l Locked % - グローバルライトロックの時間割合
l idx miss % - indexのヒット率の時間割合
l qr¦qw - 読み込みキュー¦書き込みキュー の大きさ
13年12月12日木曜日
- 85. n mongostat - 見るべき項目
l faults が多い場合
キャッシュメモリ溢れの可能性があるので、メモリ、
もしくはサーバを増設
l Locked % が高い場合
書き込みのクエリを見直す or クラスタ分割。
l qr¦qw が高い場合
サーバ負荷が低ければ、ロックの可能性を疑う。負荷
が高ければ単純なクエリ増による高負荷を疑う。
13年12月12日木曜日
- 86. n mongotop
l 現在重いmongodのどのcollectionへアクセスがか
かっているかを確認したりとかできまする。
l 障害の時がメイン
$ /usr/local/mongodb2_1/bin/mongotop --host
mongos_ip --port 27018
connected to: mongos_ip
ns total
read
write
2012-05-23T02:14:12
local.oplog.rs 1929ms 1929ms 0ms
life_prd_main.TestOnline 0ms 500ms
10ms
life_prd_main.Test2Soil 8ms
0ms
8ms
13年12月12日木曜日
writeに時間
がかかってい
- 87. n mongosniff
l 最後はパケットキャプチャですので、何か会った際の
アクセス状況の確認が可能
l mongosのアクセス状況とか、複雑なクエリを見た
い場合はこれで見るのが良い
# mongosniff --source NET eth0 27017
# 以下にパケットがズラズラっと並ぶ
127.0.0.1:55858 -->> 127.0.0.1:27017 testdatabase.TestCol1 89 bytes
id:kjkjkjkj
14086840
query: { _id: "1234567891234567" } ntoreturn: -1 ntoskip: 0
127.0.0.1:27017 <<-- 127.0.0.1:55858 205 bytes id:77383268
2000171624 - 14086840
13年12月12日木曜日
- 88. n ステータス確認・変更
l profiling
l loglevel変更
l Working Set Analyzer
l db.adminCommand("connPoolStats")
l db.serverStatus()
l db.currentOp()
l db.collection.stat()
l db.stats()
13年12月12日木曜日