Cassandra频繁读写超时

Question

我使用数据斯塔克斯java驱动程序1.0.1和卡桑德拉1.2.6.将整个代码库从节俭更改为CQL。

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

有了这个，我能够插入大量不符合节俭原则的数据…但是经过一个阶段，数据文件夹大约在3.5GB左右。我经常遇到写入超时异常。即使我再次做同样的早期工作用例，现在也会引发超时异常。它的随机曾经工作过，即使在重新设置后也无法再次工作。

CASSADNRA服务器日志

这是卡桑德拉服务器部分日志DEBUG模式，然后当我得到错误时：

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处理器…我正在使用SINGLE节点cassandra，这个yaml调整为超时，其他一切都是默认的：

< li >读取请求超时毫秒数:30000 < li >范围请求超时毫秒数:30000 < li >写入请求超时毫秒数:30000 < Li > truncate _ request _ time out _ in _ ms:60000 < li >请求超时毫秒数:30000

用例：我正在运行一个用cassandra存储Combinations（我的项目术语）的用例……目前正在测试使用100个并行线程存储250000个组合……每个线程存储一个组合…实际情况下，我需要支持数千万个，但这需要不同的硬件和多节点集群。。。

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

• 527插入查询
• 506更新查询
• 954个SELECT查询

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

我发现写超时的行为随机一段时间它工作到200 000，然后抛出超时，有时甚至不适用于10k组合。随机行为。

Answer 1

从您的日志片段来看，只有4 GB的堆被分配给了Cassandra，而且它正在变满。这很可能是你的问题:

调试 [预定任务：1] 2013-08-07 15：08：09，434 GC检查器.java（第121行） GC用于ParNew：155毫秒用于6个集合，3230372760使用;最大值为4277534720

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

Answer 2

只是花了一些时间阅读我的开发卡桑德拉节点配置yaml，因为我遇到了类似的问题。当我尝试将大约30亿个sha2哈希加载到我的开发节点时，我的系统停滞并超时，只有600MB RAM;)

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

但很抱歉，我不知道有哪些选择。我记得我读过关于性能调优以及如何基于cpu内核、ram等计算系统的正确值的文档。

我遇到的问题是缓存写入磁盘的速度不够快，所以它开始阻止一切。说完之后，更频繁地编写并让新请求等待，节点变得稳定，我的导入速度变慢了一点。

它接缝的是，cassandra的默认选项是用于在多节点集群中具有大量内核的重型冲压机械，这些机器可以分散负载。若要使其在本地开发环境中运行，请将其搞砸。它的发展环境而不是生活系统，花时间喝一两杯咖啡;)

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

Answer 3

我发现，在一些cassandra-stress读操作中，如果我将rate threads设置得太高，就会出现CL错误。考虑在测试期间将线程数量降低到您的池能够承受的水平，以战胜

< li >读取请求超时毫秒数

在我看来，在卡桑德拉.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=uniORM（1…1000000）”或您想要多少来分散读取数据。