Question

我有一个BigCouch群集， Q = 256，N = 3，R = 2，W = 2 。一切似乎都在运行，我可以阅读和编写小型测试文档。该应用程序使用Python并使用CouchDB库。该集群有3个节点，每个节点位于vxware上的CentOS上，每个节点有3个内核和6GB RAM。 BigCouch 0.4.0，CouchDB 1.1.1，Erlang R14B04，Linux版本CentOS Linux版本6.0（最终版）在EC2和CentOS版本6.2（最终版）上的vmware 5.0。

启动应用程序尝试使用412个文档和总共490KB数据进行批量插入。这适用于 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}]}”

“进程错误＆lt; 0.13489.10＆gt;节点'bigcouch-test02@bigcouch-test02.oceanobservatories.org'，退出值为：{{badmatch，{error，timeout}}，[{couch_db，' - load_validation_funs / 1-乐趣-1 - ”，1}]}“

当然还有Erlang转储。

从阅读其他人对BigCouch的使用来看，这肯定不是一个大的更新。我们的虚拟机似乎足够强大。我可以使用cURL和JSON文件重现，因此它不是应用程序。（如果它有帮助，也可以发布。）

有谁可以解释为什么9核和18GB RAM无法处理（3x）490KB写入？

如果有帮助，请提供更多信息：

bigcouch.log条目，包括较长的崩溃报告
JSON entries可重复导致失败
erl_crash.dump m1.small尝试分配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"

Answer 1

得到一个建议，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的致命弱点：尽管建议过度支持群集的后期增长，除非您已经拥有中等规模的群集或强大的硬件，否则您无法拥有足够的分片！

490KB插入崩溃BigCouch

1 个答案: