10

我已经将整个代码库ThriftCQL使用datastax java driver 1.0.1cassandra 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 回答