我注意到随着时间的推移连续写入会导致Cassandra写入性能严重下降。
我在时间戳（T）中插入时间序列数据作为列名称，在一列中存储24小时的数据。 流数据从数据生成器（4个实例，每个实例具有256个线程）写入，并行地将数据插入多个行。 此外，数据还会插入到具有DateType和UUIDType索引的列族中。
CF1：
Col1 | Col2 | Col3(DateType) | Col(UUIDType4) |
RowKey1
RowKey2
CF2（宽柱系列）：
RowKey1（T1，V1）（T2，V3）（T4，V4）......
RowKey2（T1，V1）（T3，V3）.....
没有。插入的数据点数/秒随时间减少，直到无法进一步插入为止。初始性能大约为60000 ops / sec，持续约6-8小时，然后逐渐逐渐减小到0 ops / sec。在所有节点上重新启动DataStax_Cassandra_Community_Server有助于恢复原始吞吐量，但几小时后会再次观察到该行为。
操作系统：Windows Server 2008 节点数：5 Cassandra版本：DataStax社区1.2.3 内存：8GB HeapSize：3GB 垃圾收集器：默认设置[ParNewGC]
我也注意到no的显着增加。当性能开始下降时，OpsCenter报告的待处理写入请求（大约200,000）。
我无法理解是什么阻止了写操作的完成以及为什么它们会随着时间的推移而堆积？我没有在Cassandra日志中看到任何可疑的东西。
操作系统设置是否与此有关？ 有什么建议可以进一步探讨这个问题吗？
答案 0 :(得分：3)
您是否看到待处理的压缩（nodetool compactionstats）有所增加？或者你看到被阻止的刷新写入器（nodetool tpstats）？我猜你正在把数据写入Cassandra的速度超过它可以消耗的速度。
Cassandra不会阻止写入，但这并不意味着您不会看到堆使用量增加。挂起的写入有开销，封锁的memtables也是如此。此外，每个SSTable都有一些内存开销。如果压缩落后，则会放大。在某些时候，您的堆中可能没有足够的空间来分配单次写入所需的对象，并且您最终会花费所有时间等待GC无法提供的分配。
随着总容量的增加或消耗数据的机器上的IO越多，您就能够维持此写入速率，但是一切都表明您没有足够的容量来维持该负载。
答案 1 :(得分：2)
使你的写入超时与2.0中的新默认值（2s而不是10s）一致，将有助于你的写入积压，允许减载速度更快：https://issues.apache.org/jira/browse/CASSANDRA-6059