私たちはソファベースのベンチマークを行っており、非常に奇妙な動作を観察しています。
セットアップ フェーズ:
Couchbase クラスタ マシン。
2 x EC2 r3.xlarge、汎用 80GB SSD (EBS 最適化ではありません)、IOPS 240/3000。
カウチベースの設定:
クラスター: データ RAM クォータ: 22407 MB
インデックス RAM クォータ: 2024 MB
インデックス設定 (デフォルト)
バケット:
ノードごと RAM クォータ: 22407 MB
合計バケット サイズ: 44814 MB (22407 x 2)
レプリカが有効 (1)
ディスク I/O 最適化 (低い）
各ノードは 3 つのサービスすべてを実行します
Couchbase クライアント;
1 x EC2 m4.xlarge 汎用 20 GB SSD (EBS 最適化)、IOPS 60/3000。
クライアントは「YCSB」ベンチマーク ツールを実行しています。
ycsb ロード カウチベース -s -P ワークロード/ワークロードa -p レコード数=100000000 -p コアワークロード_挿入_再試行制限=3 -p カウチベース.url= http://HOST:8091/プール-p カウチベース.バケット=テスト -スレッド 20 | ティーworkloadaLoad.dat
PS: すべてのマシンが同じ VPC とサブネット内に存在します。
結果：
すべてが期待どおりに機能しますが
、平均 ops/sec は ~21000 です
。「ディスク書き込みキュー」グラフは 200K から 600K の間で変動します (定期的に排出されます)。
「temp OOM per sec」グラフは定数 0 です。
事態がおかしくなり始めたとき
約 2,700 万のドキュメントが挿入された後、「ディスク書き込みキュー」が絶えず上昇していることを確認し始めます (排出されていません)
約 8M のディスク キュー サイズで、OOM の失敗がそれ自体を示し始め、クライアントは「一時的な」メッセージを受信しますソファベースからの失敗。
各 YCSB スレッドを 3 回再試行した後、クライアントはドキュメント全体の約 27% のみを挿入した後に停止します。
YCSB クライアントが実行を停止した場合でも、「ディスク書き込みキュー」は漸近的に 0 に向かって移動し、約 15 分後にのみ排出されます。
PS 16 GB の RAM + SSD ディスク (ローカル クライアント + 1 つのノード サーバー) を搭載した MacBook でローカルにベンチマークを行った場合、そのような動作は観察されず、「ディスク書き込みキュー」は予測可能な方法で常に排出されます。
ありがとう。