LevelDBの場合、主張されている「公式」パフォーマンスレポートと同じようにランダム書き込みのパフォーマンスを取得するにはどうすればよいですか?
-
29-10-2019 - |
質問
leveldbの公式サイト(http://code.google.com/p/leveldb/)の1つに、パフォーマンスレポートがあります。以下のように貼り付けました。
以下は公式のleveldbベンチマークからのものです
これは、含まれているdb_benchプログラムの実行からのパフォーマンスレポート(説明付き)です。結果はややうるさいですが、球場のパフォーマンスの見積もりを得るには十分なはずです。
セットアップ
100万エントリのデータベースを使用しています。各エントリには、16バイトのキーと100バイトの値があります。ベンチマークで使用される値は、元のサイズの約半分に圧縮されます。 LevelDB:バージョン1.1
CPU:4 x Intel(R)Core(TM)2 Quad CPU Q6600 @ 2.40GHz
CPUキャッシュ:4096 KB
キー:各16バイト
値:各100バイト(圧縮後50バイト)
エントリ:1000000
生のサイズ:110.6 MB(推定)
ファイルサイズ:62.9 MB(推定)
書き込みパフォーマンス
「塗りつぶし」ベンチマークは、新しいデータベースを順次またはランダムな順序で作成します。
「fillsync」ベンチマークは、すべての操作の後にオペレーティングシステムからディスクにデータをフラッシュします。他の書き込み操作では、データはしばらくの間オペレーティングシステムのバッファキャッシュに残ります。 「上書き」ベンチマークは、データベース内の既存のキーを更新するランダム書き込みを実行します。
fillseq:1.765 micros / op; 62.7MB /秒
fillsync:268.409 micros / op; 0.4 MB /秒(10000 ops)
fillrandom:2.460 micros / op; 45.0MB /秒
上書き:2.380 micros / op; 46.5MB /秒
上記の各「op」は、単一のキーと値のペアの書き込みに対応します。つまり、ランダム書き込みベンチマークは、毎秒約400,000書き込みになります。
以下は私のleveldbベンチマークからのものです
leveldbのベンチマークを実行しましたが、書き込み速度がレポートの100分の1になりました。
これが私の実験設定です:
- CPU:Intel Core2 Duo T6670 2.20GHz
- 3.0GBメモリ
- 32ビットWindows7
- 圧縮なし
- options.write_buffer_size= 100MB
- options.block_cache= 640MB
私がしたことは非常に単純です。200万の{key、value}を入力するだけで、読み取りはまったく行われません。キーは20個のランダムバイトを持つバイト配列であり、値も100個のランダムバイトを持つバイト配列です。私は常に新しくランダムな{key、value}を200万回、他の操作なしで配置しました。
私の実験では、最初から書き込み速度が低下していることがわかります。瞬時速度(1024書き込みごとの速度を測定)は、50 / sから10,000 / sの間で変動します。そして 200万ペアの全体的な平均書き込み速度は約3,000 /秒です。書き込みのピーク速度は10,000 /秒です。
レポートによると、書き込み速度は400、000 / sになる可能性があるとのことですが、ベンチマークの書き込み速度は40〜130倍遅いので、ベンチマークの何が問題になっているのでしょうか。
テストコードをここに貼り付ける必要はありません。非常に簡単です。whileループが200万回あり、ループ内では、反復ごとに20バイトのキーと100バイトが生成されます。値のバイト、そしてそれらをleveldbデータベースに置きます。 {key、value}の生成に費やされた時間も測定しました。コストは0ミリ秒です。
誰かがこれを手伝ってくれる? leveldbで400、000 / sの書き込み速度を達成するにはどうすればよいですか?どの設定に改善する必要がありますか?
ありがとう
さらに
私は自分のマチで公式のdb_bench.ccを実行しました。レポートより28倍遅いです。
私は独自のベンチマークプログラムを使用したので、私のベンチマークと彼らのベンチマークの唯一の違いはマシンだと思います。
私がしたことは非常に単純です。200万の{key、value}を入力するだけで、読み取りはまったく行われません。キーは20個のランダムバイトを持つバイト配列であり、値も100個のランダムバイトを持つバイト配列です。私は常に新しくランダムな{key、value}を200万回、他の操作なしで配置しました。
私の実験では、最初から書き込み速度が低下していることがわかります。瞬時速度(1024書き込みごとの速度を測定)は、50 / sから10,000 / sの間で変動します。そして 200万ペアの全体的な平均書き込み速度は約3,000 /秒です。書き込みのピーク速度は10,000 /秒です。
レポートによると、書き込み速度は400、000 / sになる可能性があるとのことですが、ベンチマークの書き込み速度は40〜130倍遅いので、ベンチマークの何が問題になっているのでしょうか。
テストコードをここに貼り付ける必要はありません。非常に簡単です。whileループが200万回あり、ループ内では、反復ごとに20バイトのキーと100バイトが生成されます。値のバイト、そしてそれらをleveldbデータベースに置きます。 {key、value}の生成に費やされた時間も測定しました。コストは0ミリ秒です。
誰かがこれを手伝ってくれる? leveldbで400、000 / sの書き込み速度を達成するにはどうすればよいですか?どの設定に改善する必要がありますか?
ありがとう
さらに
私は自分のマチで公式のdb_bench.ccを実行しました。レポートより28倍遅いです。
私は独自のベンチマークプログラムを使用したので、私のベンチマークと彼らのベンチマークの唯一の違いはマシンだと思います。
解決
200万のキーと値のペアがあり、各キーと値のペアは合計120バイトなので、200万* 120バイト= 228 MBのデータです。キャッシュは640MBであるため、すべてのデータがまだRAMにあり、実際にディスクに保存されていない可能性があります。 Kitsuneが指摘したように、ハードウェアはGoogleがテストしたものほど高速ではなく、Googleのキャッシュサイズが同じであれば、簡単に 30倍の違いが生じる可能性があります。
その他の潜在的な問題:
- キーがどの程度「ランダム」であったかを正確に知ることは困難です。LevelDBのパフォーマンスは、キーの分布によって異なります(「ランダム」であっても)。
- 20バイトのキーは、整列しないため、16バイトのキーよりも効率が低くなります。
- ハードドライブによっては、ディスクの書き込み速度が遅くなる場合があります(チェックします)。
私たちは何度も何度も続けることができますが、考慮すべき変数が多すぎます。テストの実行方法を示すコードを投稿する場合は、パフォーマンスを向上させるために、いくつかの最適化をお勧めします。
他のヒント
まったく異なるハードウェアで同じベンチマークを実行すると、いくつかの違いが見られるはずです。
- CPUは2xCores@2.2GHzと16xCores@2.4GHzの約9分の1です
- ハードドライブと公式ベンチマークのドライブについては言及されていません(ファイバーNASとソリッドステートドライブSSDとハードディスクドライブHDD)
リンゴをオレンジと比較したり、リンゴを[未知の果物]と比較したりすることはできません。