查询已关闭工作流时Cadence-Cassandra集群节点宕机问题求助

排查方向 #

• 检查Cassandra节点崩溃日志，优先定位**OOM（内存溢出）**相关栈信息——大查询极易触发内存耗尽，是节点宕机的核心诱因。
• 验证Cassandra内存配置：3.11.5版本heap建议上限为8G（受G1GC机制限制），heap过大/过小都会引发GC卡顿或内存不足；同时确认off-heap内存（如page cache）未被其他进程挤占。
• 分析Cadence查询请求：确认查询是否未做分页、或分页参数过大（如一次性拉取数万条），导致Cassandra需扫描大量SSTable并加载至内存。
• 检查Cadence表结构与索引：closed_workflows表是否按domain_id+close_time分区？若查询未命中分区键/索引，会触发全表扫描，直接压垮大表所在节点。
• 监控节点负载：查询时的CPU、磁盘IO、网络带宽是否达到瓶颈——磁盘IO过高会导致节点无响应，带宽不足则可能引发数据传输超时、节点被标记宕机。

修复与优化建议 #

1. 紧急修复Cassandra内存问题 #

• 调整heap大小至4-8G区间：修改cassandra-env.sh中的MAX_HEAP_SIZE（如MAX_HEAP_SIZE="8G"）和HEAP_NEWSIZE（如HEAP_NEWSIZE="2G"），重启Cassandra节点。
• 预留足够off-heap内存：关闭节点上其他高内存占用进程，或升级节点硬件内存。

2. 优化Cadence查询行为 #

• 强制分页查询：cadence-web调整默认分页大小（如从100降至20），CLI查询时添加--page-size参数，避免一次性拉取大量数据。
• 添加时间范围过滤：查询时必须带上--start-time和--end-time，缩小扫描范围，杜绝全表扫描。

3. 优化Cassandra表与集群 #

• 验证分区策略：确保closed_workflows表按domain_id和close_time分区，让查询能精准命中目标分区，减少扫描数据量。
• 合理使用二级索引：仅对高频查询字段（如workflow_type）创建二级索引，且必须配合分区键过滤使用，避免索引引发的性能开销。
• 定期合并SSTable：执行nodetool compact命令，减少查询时需扫描的文件数量，提升查询效率。
• 开启慢查询日志：在cassandra.yaml中设置slow_query_log_timeout_in_ms: 1000，记录耗时超1秒的查询，针对性优化。

4. 版本升级（长期优化） #

• 升级Cadence至稳定新版本：0.11.0版本较陈旧，后续版本对Cassandra查询做了大量优化（如高效分页、减少冗余数据拉取），建议升级至v0.23.x及以上版本。
• 升级Cassandra补丁版本：3.11.5存在已知内存泄漏和查询性能问题，可升级至3.11.x最新补丁版，或兼容前提下升级至4.x版本。

5. 集群扩容与分片 #

• 增加Cassandra节点数量：分摊大查询带来的负载，提升集群整体吞吐量。
• Cadence Domain分片：将不同Domain的工作流数据分散至不同节点，避免单个Domain的查询压垮特定节点。

内容的提问来源于stack exchange，提问作者Anush Chinoyan