卡桑德拉频繁读写超时

Question

我使用Thrift和cassandra 1.2.6..将整个代码基从datastax java driver 1.0.1更改为CQL

有了节俭，我从一开始就得到了频繁的超时，我无法proceed...Adopting CQL，表的设计是根据我的成功和更少的超时.

有了这个功能，我就可以在3.5GB左右的阶段、数据文件夹中插入无法使用thrift...But的大量数据。我经常遇到写超时异常。即使是我也做了同样的工作用例，现在也抛出超时异常。它的随机一次工作，即使在新的设置之后也不能再次工作。

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)

基础设施: 16 8GB机器，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....Currently测试中存储组合(我的项目术语)，存储25万个组合和100个并行threads..each线程，存储一个combination...real用例，我需要支持数千万个combination...real，但这需要不同的硬件和多节点集群.

在存储一个组合时，大约需要2秒，涉及：

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

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

我发现写超时的行为是随机的，在某些时间，它可以工作到20万，然后抛出超时，有时甚至对10k组合也不起作用。随机行为。

Answer 1

我发现，在一些cassandra压力读取操作中，如果我将速率线程设置得太高，我就会得到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)‘或你想要的多少来扩展读取。

Answer 2

只是花了一些时间阅读我的dev cassandra节点配置yaml，因为我也遇到了类似的问题。当我试图将大约30亿sha2散列加载到只有600 My内存的dev节点时，我的系统就停止了;)

我通过减少缓存大小和在刷新之前等待等等来修复它。这使得节点在写操作时变慢了，但是它变得稳定了。那时，我能够加载我需要的数据。

但很抱歉我想不出是哪种选择。我记得我读过关于性能调优的文档，以及如何根据cpu内核、ram等计算系统的正确值。

我遇到的问题是，缓存写入磁盘的速度不够快，所以开始阻塞所有的内容。说完之后，写得更多，让新的请求等待，节点变得稳定，我的导入速度稍微慢一点。

卡桑德拉的默认选项是用于多节点集群中具有大量核心的重型公羊maschines，这样可以扩展负载。要让它在本地开发环境上运行，就把它搞砸。而不是生命系统，花点时间喝一两杯咖啡;)

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

Answer 3

从您的日志片段中，只有4GB的堆被分配给Cassandra，并且它已经满了。这很可能是你的问题：

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为4277534720 == 4 GB堆。您应该进入cassandra-env.sh并显式地设置最大堆和新堆大小。对于您描述的节点，8 GB的最大堆和800 MB的新堆可能是一个很好的起点。