10

我已经将整个代码库Thrift从CQL使用datastax java driver 1.0.1和cassandra 1.2.6..

节俭我从一开始就经常超时，我无法继续......采用CQL，按照我成功设计的表格和更少的超时......

有了它，我就能够插入大量数据，这些数据不能与 thrift 一起使用……但经过一个阶段后，数据文件夹大约为 3.5GB。我经常收到写超时异常。即使我再次执行相同的早期工作用例，现在也会引发超时异常。即使在重新设置后，它的随机工作也不再工作。

CASSADNRA 服务器日志

这是 cassandra 服务器部分日志调试模式，当时我收到错误：

http://pastebin.com/rW0B4MD0

客户例外是：

Caused by: com.datastax.driver.core.exceptions.WriteTimeoutException: Cassandra timeout during write query at consistency ONE (1 replica were required but only 0 acknowledged the write)
    at com.datastax.driver.core.exceptions.WriteTimeoutException.copy(WriteTimeoutException.java:54)
    at com.datastax.driver.core.ResultSetFuture.extractCauseFromExecutionException(ResultSetFuture.java:214)
    at com.datastax.driver.core.ResultSetFuture.getUninterruptibly(ResultSetFuture.java:169)
    at com.datastax.driver.core.Session.execute(Session.java:107)
    at com.datastax.driver.core.Session.execute(Session.java:76)

基础设施： 16GB 机器，8GB 堆分配给 cassandra，i7 处理器。我正在使用单节点 cassandra，此 yaml 已针对超时进行了调整，其他一切都是默认设置：

  • read_request_timeout_in_ms: 30000
  • range_request_timeout_in_ms：30000
  • write_request_timeout_in_ms：30000
  • truncate_request_timeout_in_ms：60000
  • request_timeout_in_ms：30000

用例： 我正在运行一个用例，它在 cassandra 中存储组合（我的项目术语）......目前正在测试用 100 个并行线程存储 250 000 个组合......每个线程存储一个组合......我需要支持几十个的真实案例数百万，但这需要不同的硬件和多节点集群......

存储一个组合大约需要 2 秒，包括：

  • 527 插入查询
  • 506 更新查询
  • 954 选择查询

100个并行线程并行存储100个组合。

我发现 WRITE TIMEOUTS 的行为是随机的，有时它可以工作到 200 000，然后抛出超时，有时即使是 10k 组合也不起作用。随机行为。

4

4 回答 4

2

我发现在一些 cassandra-stress 读取操作期间，如果我将线程速率设置得太高，我会得到那个 CL 错误。考虑在您的测试期间将线程数降低到您的池可以承受的范围内，以便击败

  • read_request_timeout_in_ms

在我看来，在 cassandra.yaml 中修改它并不总是一个好主意。考虑您的机器使用的硬件资源。

鸡蛋：

cassandra-stress read n=100000 cl=ONE -rate threads=200 -node N1

会给我错误，而

cassandra-stress read n=100000 cl=ONE -rate threads=121 -node N1

会顺利完成这项工作。

希望能帮到大家。

PS 当您进行读取测试时，请尝试使用“-pop dist=UNIFORM(1..1000000)”或您想要多少来传播读取。

于 2016-05-29T15:00:25.473 回答
1

刚刚花了一些时间阅读我的开发 cassandra 节点配置 yaml，因为我遇到了类似的问题。当我尝试将大约 30 亿个 sha2 哈希加载到只有 600MB RAM 的开发节点时，我的系统停止并超时；）

我通过减少缓存大小并在刷新之前等待等来修复它。这使得节点的写入速度变慢，但它变得稳定了。然后，我可以根据需要加载尽可能多的数据。

但抱歉，我无法弄清楚那是哪些选项。我记得我阅读了有关性能调整以及如何根据 cpu 内核、ram 等为您的系统计算正确值的文档。

我遇到的问题是缓存写入磁盘的速度不够快，因此它开始阻塞所有内容。说完，写得更频繁，让新的请求等待，节点变得稳定，我的导入变得有点慢。

似乎 cassandra 的默认选项适用于在多节点集群中具有大量内核的重型 ram 机器，可以分散负载。为了让它在本地开发环境中运行，把它搞砸。它的开发环境而不是生活系统，花时间喝一两杯咖啡；）

希望这有助于以正确的方式思考

于 2013-08-07T11:31:36.657 回答
0

从您的日志片段中，Cassandra 只获得了 4 GB 的堆，而且堆已满。这很可能是你的问题：

DEBUG [ScheduledTasks:1] 2013-08-07 15:08:09,434 GCInspector.java (line 121) GC for ParNew: 155 ms for 6 collections, 3230372760 used; max is 4277534720

最大值为 4277534720 == 4 GB 堆。您应该进入您的 cassandra-env.sh 并明确设置最大堆和新堆大小。对于您描述的节点，8 GB 最大堆和 800 MB 新堆可能是一个很好的起点。

于 2013-08-10T17:37:53.237 回答
0

我也遇到过这个问题，“Cassandra在一致性 LOCAL_ONE（0 个副本）的写入查询期间超时确认需要写入 1”“在读取查询期间的 Cassandra 超时在一致性 LOCAL_ONE（0 个副本）确认需要写入 1”。我已经通过更改 cassandra.yaml 中的参数来处理它。在cassandra.yaml中搜索“timeout”，你会发现read_request_timeout_in_ms: 5000 write_request_timeout_in_ms: 2000 增加数字，然后重新启动“cassandra -f”。我的问题解决了。希望对你也有帮助！

于 2016-03-08T09:14:13.240 回答