crumbjpLinuxとApacheの憂鬱この広告は、90日以上更新していないブログに表示しています。DISKリードに繋げる事を意図した大きさだった。システムの2GBメモリに収まるだろう。・・・しかし、、測れど測れど、意図した通りの結果にならない・・・それで気付いた。インデックスの大きさを勘違いしていたのだ。MongoDBのインデックスは単なるコレクションでは無いようだ!1億件の数値型インデックスは2.3GBにもなる。いう訳で、1億件のコレクションのインデックスはそもそもメモリーに入らない。1ドキュメント辺り25〜26byteインデックス数値型8バイト+ドキュメントへのポインタ8バイト+メタ情報?_idインデックスは更に若干大きくなる。追記:メタじゃくてbtree実装だった。btreeの実装見てると、ほぼほぼ仕方が無い。(正しい実装)bsonの下位互換性を維持する為の部分に無駄があるね。システムのメモリサイズをはるかに超え、1クエリー中にもインデックスを舐めてく内に端からPageFaultして行く。今回は新たに件数やFETCHサイズを見直して測り直した。条件データ総量データ総量を前回の1/10=4GB程度にした。約4GBちなみに1000万件のドキュメントでの各インデックスサイズは以下の通り。_idインデックスサイズは約266MB数値型のインデックスサイズは約239MB総インデックスサイズは500MB程度でメモリーを圧迫する程でも無い。今回のクエリは全て、総データの1/10(400MB程度)をフェッチする。上記インデックスサイズと合わせても900MB程度、十分メモリに乗る算段だ。基本は出来るだけメモリー積んで、効率良く使え!という事。解りやすくグループ分け出来た。10スループット観点では4KB-400KBの間がいい感じ件数観点では小さい程早い傾向On-Memoryデータの場合Randomアクセス、Sequentialアクセスの差が無いグラフ上の逆転現象もそうだが計測誤差が大きい。Randomドキュメントサイズが4KBを大きく超えると差が小さくなる並列度を上げていくとどちらもディスクI/Oの限界(60MB/s程度)で頭打ちランダムFETCH性能オンメモリデータ結果がシーケンシャルアクセスより成績が良いが、、オンメモリではデータ領域での配置はそもそも関係ない。小さい(大量の)ドキュメントのディスクアクセスの結果が、前回の結果より10倍以上程度早い。前回はインデックスサイズが大きすぎて、一旦メモリに載せたインデックスがクエリー中にページフォルトしていた可能性が高い。実に2桁違う!40KB付近を境にドキュメントサイズが大きくなると性能差が縮んでいくスループット(MB/s)が突然数倍(60MB/s程度まで)改善するフェッチ数が少ないので一番ネックになるであろうHDDのヘッドの先頭合わせの回数が減る。1ドキュメントが大きいとシーケンシャル読みになり効率が良い。カーネル側で256KBの先読みも働くので無駄が減る(別の処理中も裏で読んでてくれる)。オーダーまで期待できるちゃんと使えば十二分早い。いうかめちゃくちゃ速い。4KB未満の小さいデータは小さい程メモリに載せないと遅くなる。(数千件/s程度なら気にしなくてよいが)40KB以上のデータはディスク運用してもそれなりに動く。128.7データ領域をランダムアクセスする条件&100スレッド大体スループットの頭打ちのラインが解る。151.0メモリーデータどのケースも申し分ない速さ。nodeでこれなら大抵困らない。148.6シーケンシャルFETCH性能ディスクデータ全体的にディスクの構造上の特徴が良く出ている。40.8データ領域をシーケンシャルアクセスする条件&10スレッドこの辺で頭打ち。214.1データ領域をシーケンシャルアクセスする条件&100スレッド並列度を上げ過ぎると逆に劣化する。超長くなったのでまとめを上に持ってきた。今時、digest認証なんかしたくないんだが。クエリーITシステムを構築するということ月別アーカイブはてなブログをはじめよう!hiropponさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。