Q=256、N=3、R=2、W=2の BigCouch クラスターがあります。すべてが稼働しているようで、小さなテスト ドキュメントを読み書きできます。アプリケーションは Python であり、CouchDB ライブラリを使用します。クラスターには 3 つのノードがあり、それぞれが vxware 上の CentOS 上にあり、それぞれ 3 つのコアと 6GB の RAM を備えています。BigCouch 0.4.0、CouchDB 1.1.1、Erlang R14B04、EC2 上の Linux バージョン CentOS Linux リリース 6.0 (最終版) および vmware 5.0 上の CentOS リリース 6.2 (最終版)。
アプリケーションを起動すると、412 個のドキュメントと合計 490 KB のデータを使用して一括挿入が試行されます。これはN=1で問題なく動作するため、内容に問題はありません。しかし、N=3の場合、次のいずれかの結果がランダムに得られるようです。
- 約9秒で書き込み完了
- 書き込みは約 24 秒で完了します (間に何もありません)
- 約 30 秒後に書き込みに失敗します (いくつかのドキュメントが挿入されました)。
- Erlang は約 30 秒後にクラッシュします (いくつかのドキュメントが挿入されました)。
vmstatは、ほぼ 100% の CPU 使用率を示しています。top は、これがほとんど Erlang プロセスであることを示しています。truss は、これがほとんど「futex」呼び出しで費やされていることを示しています。操作中にディスク使用率が上下しますが、CPU は固定されたままです。
ログには、次のような素敵なメッセージが表示されます。
「検証ファン {{badmatch, {error, timeout}}, [{couch_db, '-load_validation_funs/1-fun-1-', 1}]} を読み込めませんでした」
「ノード 'bigcouch-test02@bigcouch-test02.oceanobservatories.org' のプロセス <0.13489.10> でエラーが発生しました。終了値: {{badmatch,{error,timeout}},[{couch_db,'-load_validation_funs/1-fun] -1-',1}]}"
もちろん、Erlang ダンプもあります。
他の人々による BigCouch の使用について読むと、これは確かに大きな更新ではありません。私たちの VM は、この仕事に十分対応できるように思えます。cURLとJSONファイルで再現できるので、アプリではありません。(それが役立つ場合は、それも投稿できます。)
9 コアと 18GB RAM が (3x) 490KB 書き込みを処理できない理由を誰か説明できますか?
役立つ場合の詳細情報:
- 長いクラッシュ レポートを含むbigcouch.logエントリ
- 繰り返し失敗するJSON エントリ
- EC2 マシンからのerl_crash.dump m1.small が 500 MB のヒープを割り当てようとしている
コマンドで再現可能: 上記の JSON エントリを file.json としてダウンロード
url=http://yourhost:5984
curl -X PUT $url/test
curl -X POST $url/test/_bulk_docs -d @file.json -H "Content-Type: application/json"