Apache Cassandra 3.0.9每周偶发OperationTimedOutException求助

我之前维护过用Cassandra 3.0.x版本的服务，也碰到过类似每周偶发一次的OperationTimedOutException超时问题，结合你给出的环境信息（Cassandra 3.0.9 + com.datastax.cassandra:cassandra-driver-core:3.1.3），给你梳理几个实际排查过的方向，按优先级来：

这是最常见的原因，因为每周偶发大概率和固定周期的任务有关：

• 检查Cassandra节点每周固定时间是否有周期性运维任务：比如每周一次的全量快照备份（nodetool snapshot）、压缩操作（尤其是用SizeTieredCompactionStrategy的集群，大文件合并会瞬间占满磁盘IO）、或者监控系统的全量巡检脚本。这些操作会导致节点CPU、磁盘IO飙升，无法及时响应客户端请求。
• 直接去对应节点的Cassandra日志（默认路径/var/log/cassandra/system.log），在超时发生的时间点附近，搜索Compaction、Snapshot、GC这些关键词，看是否有耗时较长的操作记录。
• 超时发生后，立刻用nodetool tpstats查看线程池状态，重点关注read_requests、write_requests的pending队列长度，以及blocked线程数是否异常偏高。

Cassandra 3.0.x默认使用CMS垃圾收集器，每周偶发的超时很多时候和长时间Full GC卡顿有关：

• 如果Full GC的耗时超过了driver配置的请求超时阈值（driver 3.x默认是10秒），节点就会完全无法处理请求，直接触发超时。
• 先确认是否开启了GC日志，如果没开，给JVM加上参数：-Xloggc:/path/to/gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps，等下次超时发生后，查看对应时间点的GC日志，看是否有耗时超过10秒的Full GC。
• 日常可以用nodetool gcstats查看Cassandra的GC统计数据，或者用jstat -gc <cassandra_pid> 1000实时监控GC情况，看是否有每周周期性的GC峰值。

虽然你的driver版本和Cassandra版本是兼容的，但还是要检查几个关键配置：

• 请求超时时间：默认的request_timeout是10秒，如果集群确实有偶尔的慢操作，可以临时调大到15秒（在driver配置里设置withRequestTimeout(Duration.ofSeconds(15))），但这只是缓解，核心还是要找到超时根源。
• 连接池配置：检查core_connections_per_host、max_connections_per_host是否足够，是否有连接池耗尽的情况。可以在应用日志里搜索ConnectionPool相关的日志，看是否有“waiting for connection”之类的记录。
• 负载均衡与节点状态：默认的DCAwareRoundRobinPolicy会优先请求本地数据中心节点，如果超时的那个节点（xxx.xx.xx.xx:9042）在对应时间点被driver标记为不可用，可能导致请求集中到其他节点，引发负载过高超时。

有时候问题出在底层：

• 检查超时节点的网络状态：在超时时间段前后，用ping、mtr监控节点的网络延迟和丢包情况，看是否有网络波动。必要时可以用tcpdump抓包，分析是否有TCP连接异常。
• 磁盘性能排查：Cassandra严重依赖磁盘IO，用iostat -x 1查看节点的磁盘使用率、IOPS、读写延迟，如果%util接近100%或者延迟超过几十毫秒，说明磁盘IO是瓶颈。

最后排查应用侧的查询：

• 检查是否有周期性的大查询：比如每周一次的报表生成，一次性读取大量数据（比如没有限制分区键的SELECT *查询），导致节点压力骤增。
• 如果开启了查询追踪，可以去system_traces.sessions表中，搜索超时时间点附近的慢查询，看是否有不符合Cassandra数据模型的查询（比如大范围扫描、多分区查询）。

另外提一句，Cassandra 3.0.9是比较老的版本了，后续如果有机会，建议升级到3.11.x分支，这个分支修复了很多3.0.x的性能和稳定性问题，能减少这类偶发异常的概率。

内容的提问来源于stack exchange，提问作者Pankaj Yadav