Cassandra 频繁读写超时问题

Question

我已经使用datastax java driver 1.0.1和cassandra 1.2.6将代码库从Thrift更改为CQL。

使用Thrift时，我从一开始就经常出现超时错误，无法进行下去......采用CQL之后，按照其设计的表我获得了成功并减少了超时情况......

有了这个变化后，我能够插入大量数据，这些数据在使用Thrift时无法工作......但是在一个阶段后，数据文件夹大小约为3.5GB。我会经常收到写入超时异常。即使我重新设置相同的先前可用的用例，现在也会抛出超时异常。它是随机的，曾经有效现在不再有效。

CASSADNRA SERVER LOG

这是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堆大小，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个INSERT INTO查询
• 506个UPDATE查询
• 954个SELECT查询

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

我发现写入超时的行为是随机的，有时可以工作到200,000个组合，然后会抛出超时异常，而有时甚至无法工作10,000个组合。这种行为是随机的。

- user2572801

---

停止在DEBUG级别记录日志，查看Statuslogger在INFO级别下的输出。 - jbellis

Answer 1

我发现在一些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

会顺利完成工作。

希望它能帮助你们。

附：当你进行读取测试时，尝试将阅读分散在数据上，即使用“-pop dist = UNIFORM（1..1000000）”或其他数量。

- Mr'Black

Answer 2

花了一些时间阅读我的开发Cassandra节点配置yaml文件，因为我遇到了类似的问题。当我尝试将约30亿个SHA2哈希加载到只有600MB RAM的开发节点上时，我的系统停滞并抛出超时异常；）

我通过减小缓存大小和等待刷新等方式来解决这个问题。这使得节点在写入方面变慢，但它变得更稳定了。然后我可以加载尽可能多的数据。

但很抱歉我没有想清楚是哪些选项。 我记得我阅读了有关性能调优以及如何根据CPU核心、RAM等计算系统正确值的文档。

我遇到的问题是缓存写入磁盘的速度不够快，因此开始阻塞一切。在建议更频繁地写入并让新请求等待后，该节点变得更加稳定，我的导入稍微变慢了一点。

看起来Cassandra的默认选项适用于具有大量核心的重型RAM设备的多节点集群，可以分散负载。要在本地开发环境中运行它，请降低参数设置。这是开发环境，而不是生产系统，花点时间喝咖啡或两杯;)

希望这可以帮助您正确思考

- Rene M.

---

非常感谢，我会尝试那个方向来检查是否有效。我的情况是，在处理大量负载时，有1-2次它可以工作，但大多数情况下，即使负载比之前成功的情况还要小，它也无法正常工作...这就是为什么我感到困惑，如果没有系统更改，为什么它不能再次工作。 - user2572801

Answer 3

我也遇到了这个问题，“Cassandra timeout during write query at consistency LOCAL_ONE (0 replicas) acknowledged the write over 1 required”和“Cassandra timeout during read query at consistency LOCAL_ONE (0 replicas) acknowledged the write over 1 required”。我通过更改cassandra.yaml中的参数来解决它。在cassandra.yaml中搜索“timeout”，您会发现read_request_timeout_in_ms: 5000和write_request_timeout_in_ms: 2000。增加这些数字，然后重新启动“cassandra -f”。我的问题得到了解决。希望这也能帮助到您！

- David

Answer 4

从您的日志片段中可以看到，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

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

- Zanson