3

我有一个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 版本 CentOS Linux 版本 6.0（最终版）在 EC2 上和 CentOS 版本 6.2（最终版）在 vmware 5.0 上。

启动应用程序尝试使用 412 个文档和总共 490KB 的数据进行批量插入。这适用于N=1，因此内容没有问题。但是当N=3我似乎随机得到以下结果之一：

  • 写入在大约 9 秒内完成
  • 写入在大约 24 秒内完成（中间没有任何时间）
  • 大约 30 秒后写入失败（插入了一些文档）
  • 大约 30 秒后 Erlang 崩溃（插入了一些文档）

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 的信息来看，这当然不是一个大的更新。我们的虚拟机似乎足以胜任这项工作。我可以用 cURL 和 JSON 文件重现，所以它不是应用程序。（如果有帮助也可以发布。）

谁能解释为什么 9 核和 18GB RAM 不能处理（3x）490KB 写入？

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

可以使用命令重现：将上面的 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"
4

1 回答 1

0

有人建议 Q=256 可能是问题所在，并发现随着 Q 的增长，BigCouch 确实会减慢很多。这让我很惊讶——我认为散列和委托会非常轻量级。但也许它为每个 DB 分片分配了太多资源。

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

于 2012-10-15T21:15:30.523 回答