MongoDB Insert の性能について

[Nishimura Ryuichiro]

単純にMongoDBにドキュメント(1ドキュメント500Bytesくらい)をひたすら登録する時の

性能を確認しています。

運用上、バルクにできるサイズが限られているので、10ドキュメントのバルクで登録して

います。

また、システム構成はシャーディングを組まずに、単一サーバーでの確認になります。

現状、1sec に、15,000件程度の Insert をしています。

この件数が妥当なのかどうかがまず不明なのですが、

・ログを確認すると、非常に多くのロック情報が出力されています。mongostatで確認

　しても、平均的に 50-60% ほどのロックが発生しています。

　あるHPを見ると、ロックが 80% とかを超えだすと注意、みたいな感じの記事が出て

　いたのですが、やはりこれくらいのロックまでは許容できるものなんでしょうか？

・ログからロック時間を確認したところ、ロックを起こさせないようにすると、数%

　くらいの性能向上もありそうなのですが、ロックを起こさせないようにするには、

　MongoDBとしてどんな手があるでしょうか。

　そもそも、ロックってどこで発生している？

・さらにパフォーマンスの向上が見込めないかを検討中ですが、

　○ジャーナルをとらないようにする（<- 確認済みで、数%-10数%ほどの向上がありま

　　した。）

　○シャーディング環境にする（<-先にも書きましたが、これについては今回は検討の

　　対象外としています。）

　の他に何かあればご意見をいただきたく。

ずらずらと書き連ねましたが、15,000/sec の Insert 自体はすごいことだと思っています。

以上、ご指摘等お願いします。

[Nishimura Ryuichiro]

補足情報：

登録処理は単一プロセスでシーケンシャルに行っています。

例）

for(i=0;i<xxxxxxxxxxx;i++){

db.test.insert({[{データ},{データ},{データ},・・・]})　<- Bulk Insert

}

2014年7月9日水曜日 5時49分15秒 UTC+9 Nishimura Ryuichiro:

[Hiroaki Kubota]

insert性能はそんなものですね。
4kb以外のレコードは大体10000件/sec超える位です。

手前味噌ながら、理由も含めてこの辺で検証してます
http://d.hatena.ne.jp/hiroppon/touch/20130515/1368612212

参考にしてもらえれば、、、
2014/07/09 5:49 "Nishimura Ryuichiro" <nish...@gmail.com>:

> --
> このメールは Google グループのグループ「MongoDB JP」に登録しているユーザーに送られています。
> このグループから退会し、グループからのメールの配信を停止するには mongodb-jp+...@googlegroups.com にメールを送信してください。
> このグループに投稿するには mongo...@googlegroups.com にメールを送信してください。
> http://groups.google.com/group/mongodb-jp からこのグループにアクセスしてください。
> その他のオプションについては https://groups.google.com/d/optout にアクセスしてください。

[Nishimura Ryuichiro]

crumbjp さん

いつも早い回答ありがとうございます。

やっぱり性能的にはこれくらいなんですねー。

性能結果として不満足な訳ではないので、そういうことなんだ、ということで

認識しておきます。

参考資料、教えていただきありがとうございました。

西村

2014年7月10日木曜日 19時03分50秒 UTC+9 crumbjp:

[Nishimura Ryuichiro]

本件に関連しての投稿になります。

プログラムでループして、データをひたすら登録するプログラムを動かすの

ですが、

・登録のたびに、DB の OPEN(connect)、CLOSE(disconnect) を繰り返す

・OPEN はプログラム起動時に 1 回だけ行い、そのコネクションでひたすら

　登録処理

の 2 パターンを確認したところ、登録のたびに接続・切断する方がパフォー

マンスがいいようでした。

ログを見てみると、ロック情報が出ていなかったので、ロック遅延がなかっ

たことが原因ではないかと思っています。

（別環境で試したところ、完全にロックがなくなる訳でもないみたいですが、

頻度は明らかな少ないようでした。）

RDB を使っていた時は、パフォーマンスが悪くなるからなどの理由で、コネ

クションの接続・切断は毎回やらないようにしていたのですが、MongoDB 

はそうではないんでしょうか。

基本的には、コネクションの接続・切断は毎回やる必要はないと考えています。

西村

2014年7月9日水曜日 5時49分15秒 UTC+9 Nishimura Ryuichiro:

単純にMongoDBにドキュメント(1ドキュメント500Bytesくらい)をひたすら登録する時の

[Hiroaki Kubota]

恐らくそれは間違いです。
本来、全く比較にならない差が出るはずです。

大抵のドライバーは裏にコネクションプールを持っていてそれを使っているはずです。（コネクションストリングをキーにして持つ実装が一般的）
その場合、アプリがコネクションをプールに返してあげない、リーク検知のタイミングまで、新しいコネクションをどんどん張るでしょう。
なのである程度の差が出るのではないかと思います。

2014年7月22日 6:14 Nishimura Ryuichiro <nish...@gmail.com>:

[Nishimura Ryuichiro]

ご指摘ありがとうございました。

私もおかしな事象だなと思っていたので、自分で試してみました。

（この結果は他の者から聞いたので、直接確認はしていませんでした。）

結果は、やはり、性能差（処理時間差）が出ました。

おそらくソケットの問題（OPEN/CLOSE の繰り返しで、やたらと

TIME_WAIT のセッションが残ってしまい、使えるポート範囲を全

て使い切ってしまうことがあった）か何かの影響で、データがド

ロップしてしまうとか、時間差が極端に出てしまうとか、の問題が

ありましたが、数倍の差が確認できました。

おそらく、前回確認した時の設定がきちんとできていなかったため

ではないかと思われます。

やはり、MongoDB でも、余計な OPEN/CLOSE はしない方がよい

ということでしょうか。

お手数をおかけしました。

西村

2014年7月22日火曜日 22時49分42秒 UTC+9 crumbjp:

[Nishimura Ryuichiro]

以前、他の投稿にも上げられているのですが、Insert をひたすら続けて

いくと、徐々にパフォーマンスが落ちてきているように感じます。

データファイルサイズは総計で 10GB 近くにはなっているのですが、

MAX 2GB のファイルが多く作成されるだけで、これが直接パフォーマ

ンスに影響するとは考えていないのですが、そのようなものなんでしょ

うか。

（実メモリサイズは 8GB の試験機で確認しています。）

1 日分の情報として、おおよそこれくらいのサイズになるデータを集め

ようとしているのですが、やはりこれくらいになってくると、

・コレクション分け

・シャーディング

などでスケールアウトしていかないといけないんでしょうか。

西村

2014年7月23日水曜日 5時27分54秒 UTC+9 Nishimura Ryuichiro:

[Hiroaki Kubota]

10GB程度で問題を感じたことは無いです。
500GB位から色々気になる点があります

もう少し情報が無いと何とも言えませんね。

mmap周りだとするとdirty page周りの動きは気になります。

2014/07/29 5:54 "Nishimura Ryuichiro" <nish...@gmail.com>: