我有一个由Java客户端应用程序使用的4个节点的Cassandra（2.2.1）集群。复制因子为3，读取和写入的一致性级别为LOCAL_QUORUM。每个节点都有大约5 GB的数据。请求数量约为每秒2-4k。几乎没有删除操作，因此创建了少量的墓碑。Cassandra集群性能不佳
我注意到前段时间的读写性能很差，而且随着时间的推移它越来越差 - 集群变得非常慢。阅读（主要是经常）和写超时已经变得非常频繁。硬件不应该导致问题，在磁盘性能，CPU和RAM资源方面，部署集群的服务器确实很好。
问题的原因我不清楚，但我已经注意到这可能指向根源几个日志条目：
在Java客户端应用程序日志异常堆栈跟踪：
COM .datastax.driver.core.exceptions.ReadTimeoutException：在一致性LOCAL_QUORUM读取查询期间卡桑德拉超时（被要求2层的反应，但只有1复制品回应）
有趣的是，1节点仍然响应。
失败提示错误的若干项：
无法重放提示来/1.1.1.1;中止（135922已交付），错误：操作超时 - 仅收到0个响应。在卡桑德拉日志
几个以下例外：
请求期间意外的异常;通道= [id：0x10fc77df，/2.2.2.2:54459：> /1.1.1.1:9042] java.io.IOException：读取时出错（...）：连接超时 at io.netty.channel.epoll .Native.readAddress（Native Method）〜[netty-all-4.0.23.Final.jar：4.0.23.Final] at io.netty.channel.epoll.EpollSocketChannel $ EpollSocketUnsafe.doReadBytes（EpollSocketChannel.java:675） 〜[netty-all-4.0.23.Final.jar：4.0.23.Final] at io.netty.channel.epoll.EpollSocketChannel $ EpollSocketUnsafe.epollInReady（EpollSocketChannel.java:714）〜[netty-all-4.0。 23.Final.jar：4.0.23.Final] at io.netty.channel.epoll.EpollEventLoop.processReady（EpollEventLoop.java:326）〜[netty-all-4.0.23.Final.jar：4.0.23。最终] at io.netty.i0.netty.channel.epoll.EpollEventLoop.run（EpollEventLoop.java:264）〜[netty-all-4.0.23.Final.jar：4.0.23.Final] at io.netty。 util.concurrent.SingleThreadEventExecutor $ 2.run（SingleThreadEventExecutor.java:116）〜[netty-all-4.0.23.Final.jar：4.0.23.Final] at io.netty.util.concurrent.DefaultThreadFactory $ DefaultRunnableDecorator.run （DefaultThreadFactory.java:137）〜[netty-all-4.0.23.Final.jar：4.0.23.Final] at java.lang.Thread.run（Thread.java:745）[na：1.8.0_66]
失败批次错误：
准备语句的批次为[< ...>]是大小3453794的，由2429794.超过1024000指定的阈值（见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] at java.io.BufferedOutputStream.flushBuffer（BufferedOutputStream.java:82）〜[na：1.8.0_66] at java.io.BufferedOutputStream.flush（BufferedOutputStream.java:140）〜[na ：1.8.0_66] at org.apache.thrift.transport.TIOStreamTransport.close（TIOStreamTransport.java:110）〜 [libthrift-0.9.2.jar：0.9.2] at org.apache.cassandra.thrift.TCustomSocket.close（TCustomSocket.java:197）[apache-cassandra-2.2.1.jar：2.2.1] at org.apache.thrif t.transport.TFramedTransport.close（TFramedTransport.java:89）[libthrift-0.9.2.jar：0.9.2] at org.apache.cassandra.thrift.CustomTThreadPoolServer $ WorkerProcess.run（CustomTThreadPoolServer.java:209）[ apache-cassandra-2.2.1.jar：2.2.1] at java.util.concurrent.ThreadPoolExecutor.runWorker（ThreadPoolExecutor.java:1142）[na：1.8.0_66] at 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的表现。 –
是的，我只是为了原子原因而进行批处理。我只是想 - 可以大批量减慢整个集群吗？ – Atver
是的，大量批次会降低性能。 –