我有一个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，Linux版本EC2上的CentOS Linux发行版6.0（最终版）和vmware 5.0上的CentOS发行版6.2（最终版）。
启动该应用程序尝试对412个文档和总共490KB数据进行批量插入。在N = 1的情况下可以正常工作，因此内容没有问题。但是，当N = 3时，我似乎会随机获得以下结果之一：
写入大约需要9秒
写入大约在24秒内完成（两者之间没有任何时间）
大约30秒后写入失败（插入了一些文档）
Erlang在大约30秒后崩溃（插入了一些文档）
vmstat显示接近100％的CPU利用率，顶部显示这主要是Erlang进程，truss显示这主要花费在“ futex”调用中。在操作过程中，磁盘使用量会上下波动，但CPU仍保持固定状态。
日志显示可爱的消息，例如：
“无法加载验证乐趣{{badmatch，{error，timeout}}，[{couch_db，'-load_validation_funs / 1-fun-1-'，1}]}”
“节点'[email protected]'上的进程中的错误，退出值为：{{badmatch，{error，timeout}}，[{couch_db，'-load_validation_funs / 1-fun -1-'，1}]}“
当然还有Erlang转储。
通过阅读有关其他人使用BigCouch的信息，这当然不是一个很大的更新。我们的虚拟机似乎足够胜任这项工作。我可以使用cURL和JSON文件进行复制，因此它不是应用程序。 （如果有帮助，也可以发布。）
谁能解释为什么9核和18GB RAM无法处理（3x）490KB写操作？
更多信息，以防万一：
bigcouch.log条目，包括更长的崩溃报告
反复导致失败的JSON entries
从EC2机器m1.small尝试erl_crash.dump尝试分配500mb堆
可以使用以下命令重现：
将上述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"
最佳答案
有人暗示Q = 256可能是问题所在，并发现随着Q的增长，BigCouch确实放慢了速度。这让我感到惊讶-我认为哈希和委派将是非常轻量级的。但这可能会为每个数据库分片分配过多的资源。
随着Q的增长变得太小而无法允许任何实际的集群增长到足以容纳BigData的程度，我进行490kb更新的时间从令人不快的缓慢增长到了不合理的缓慢，最终进入了BigCouch崩溃的境界。这是插入时间，因为Q随N = 3，R = W = 2、3个节点而变化，如最初所述：
Q sec
4 6.4
8 7.7
16 10.8
32 16.9
64 37.0 <-- specific suggestion in adam@cloudant's webcast
对于BigCouch来说，这似乎是一个致命弱点：尽管建议过分分片以支持群集的后续增长，但是除非拥有中等大小的群集或某些强大的硬件，否则您将无法拥有足够的分片！