我有一个由4个节点组成的Cassandra（2.2.1）集群，供Java客户端应用程序使用。复制因子为3，读和写的一致性级别为LOCAL_QUORUM。每个节点大约有5 GB的数据。请求量约为每秒2-4k。几乎没有删除操作，因此创建了少量的逻辑删除。
我注意到一段时间前的读写性能很差，并且随着时间的推移变得越来越差-群集的运行速度确实很慢。读（大多数情况下）和写超时已变得非常频繁。硬件不应引起问题，部署集群的服务器在磁盘性能，CPU和RAM资源方面确实不错。
对于我来说，问题的原因尚不清楚，但是我注意到一些日志条目可能指向根本原因：
Java客户端应用程序日志中的异常堆栈跟踪：
com.datastax.driver.core.exceptions.ReadTimeoutException：一致性为LOCAL_QUORUM的读取查询期间的Cassandra超时（需要2个响应，但仅响应1个副本）
有趣的是1个节点仍然响应。
失败提示错误的多个条目：
/1.1.1.1的重播提示失败；正在中止（传送135922），错误：操作超时-仅收到0个响应。
cassandra日志中的以下几种例外情况：
请求期间发生意外异常；频道= [id：0x10fc77df，/2.2.2.2:54459：> /1.1.1.1:9042]
java.io.IOException：读取时出错（...）：连接超时
在io.netty.channel.epoll.Native.readAddress（本机方法）〜[netty-all-4.0.23.Final.jar：4.0.23.Final]
在io.netty.channel.epoll.EpollSocketChannel $ EpollSocketUnsafe.doReadBytes（EpollSocketChannel.java:675）〜[netty-all-4.0.23.Final.jar：4.0.23.Final]
在io.netty.channel.epoll.EpollSocketChannel $ EpollSocketUnsafe.epollInReady（EpollSocketChannel.java:714）〜[netty-all-4.0.23.Final.jar：4.0.23.Final]
在io.netty.channel.epoll.EpollEventLoop.processReady（EpollEventLoop.java:326）〜[netty-all-4.0.23.Final.jar：4.0.23.Final]
在io.netty.channel.epoll.EpollEventLoop.run（EpollEventLoop.java:264）〜[netty-all-4.0.23.Final.jar：4.0.23.Final]
在io.netty.util.concurrent.SingleThreadEventExecutor $ 2.run（SingleThreadEventExecutor.java:116）〜[netty-all-4.0.23.Final.jar：4.0.23.Final]
在io.netty.util.concurrent.DefaultThreadFactory $ DefaultRunnableDecorator.run（DefaultThreadFactory.java:137）〜[netty-all-4.0.23.Final.jar：4.0.23.Final]
在java.lang.Thread.run（Thread.java:745）[na：1.8.0_66]
批处理失败错误：
[<...>]的准备好的语句的批处理的大小为3453794，超出了指定的阈值1024000的2429794。（请参阅batch_size_fail_threshold_in_kb）
看起来批处理太大，顺便说一下，我们有很多批处理操作。也许批次会影响系统？
最后，最常见的异常-将日志记录级别切换为DEBUG后，这些条目会依次出现：
TIOStreamTransport.java:112-关闭输出流时出错。
java.net.SocketException：套接字已关闭
在java.net.SocketOutputStream.socketWrite（SocketOutputStream.java:116）〜[na：1.8.0_66]
在java.net.SocketOutputStream.write（SocketOutputStream.java:153）〜[na：1.8.0_66]
在java.io.BufferedOutputStream.flushBuffer（BufferedOutputStream.java:82）〜[na：1.8.0_66]
在java.io.BufferedOutputStream.flush（BufferedOutputStream.java:140）〜[na：1.8.0_66]
在java.io.FilterOutputStream.close（FilterOutputStream.java:158）〜[na：1.8.0_66]
在org.apache.thrift.transport.TIOStreamTransport.close（TIOStreamTransport.java:110）〜[libthrift-0.9.2.jar：0.9.2]
在org.apache.cassandra.thrift.TCustomSocket.close（TCustomSocket.java:197）[apache-cassandra-2.2.1.jar：2.2.1]
在org.apache.thrift.transport.TFramedTransport.close（TFramedTransport.java:89）[libthrift-0.9.2.jar：0.9.2]
在org.apache.cassandra.thrift.CustomTThreadPoolServer $ WorkerProcess.run（CustomTThreadPoolServer.java:209）[apache-cassandra-2.2.1.jar：2.2.1]
在java.util.concurrent.ThreadPoolExecutor.runWorker（ThreadPoolExecutor.java:1142）[na：1.8.0_66]
在java.util.concurrent.ThreadPoolExecutor $ Worker.run（ThreadPoolExecutor.java:617）[na：1.8.0_66]
在java.lang.Thread.run（Thread.java:745）[na：1.8.0_66]
您对导致此问题的原因有任何想法吗？
谢谢！
最佳答案
关于第一点，我有一个主意：
发出查询时，总会有一个线程来处理它。
如果太多，那么应该将它们组织起来的队列。
线程在队列中等待的时间也有超时。
因此，您的副本副本回复速度不够快，因为为特定查询提供服务的线程中有一些被丢弃了。
考虑使用一些写/读线程。如果您的系统足够好，则可以在该区域分配更多的工作人员。
我记得玩卡桑德拉（Cassandra）压力过一段时间，并且速率线程=
其中默认值为32。考虑在cassandra.yaml中增加
parallel_reads从32到128
parallel_writes从32到128
您也可以考虑减少数字。我建议测试并重新测试。
您可能还会玩超时（一个队列中可以容纳多少线程来提供响应）
read_request_timeout_in_ms从5000到10000
write_request_timeout_in_ms从2000一直到5000。
在第2点上，我也怀疑相同，您的节点正在尝试回答这些提示，因此发生了两件事：
没有到达节点（检查一些网络问题）
也许您需要分配更多的工作线程，从而影响max_hints_delivery_threads。
点3看起来与点1有关。
祝好运。
关于java - Cassandra 集群性能不佳，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/39809007/