无法连接Scylla集群：CONTROL_CONNECTION_FAILED及过载排查问询

问题根源定位 #

从你提供的日志来看，reader_concurrency_semaphore信号量已完全耗尽（100/100 count），同时有大量读请求处于等待状态——这是读并发资源耗尽的明确信号，也是导致连接初始化超时的核心原因。即使节点整体CPU、内存负载看似正常，Scylla的shard级资源瓶颈也会引发这类问题。

关键过载监控指标（Scylla服务端） #

• 读并发信号量：
  • 监控scylla_semaphore_active{name="_read_concurrency_sem"}：当数值达到配置阈值（默认100）时，说明读并发资源已耗尽
  • 监控scylla_semaphore_pending{name="_read_concurrency_sem"}：持续增长的pending数表示读请求大量堆积
• 请求延迟：
  • scylla_storage_proxy_coordinator_read_latency的p99/p999分位值：若延迟远超业务正常范围，说明请求处理效率极低
• 磁盘IO状态：
  • scylla_disk_read_bytes_total/scylla_disk_write_bytes_total：磁盘吞吐量是否达到硬件上限
  • scylla_disk_pending_ops：等待处理的磁盘IO请求数，持续高位意味着磁盘IO过载
• shard负载均衡：
  • scylla_shard_cpu_usage：Scylla基于shard调度请求，单shard CPU占用过高会成为全局瓶颈，即使节点整体负载正常
• 缓存与内存：
  • scylla_cache_hit_rate：缓存命中率过低会触发大量磁盘读，加剧读并发压力
  • scylla_memory_total_used：节点内存是否接近上限，内存不足会导致频繁GC或资源分配失败

临时缓解措施 #

1. 调整读并发阈值：临时修改scylla.yaml中的read_concurrency_semaphore参数（需根据节点内存容量调整，避免OOM）
2. 排查热点请求：通过system_traces.events表定位慢查询或热点key，优化查询语句或调整数据分布
3. 扩容或分片：若长期存在并发压力，考虑增加节点或调整表的分片策略分散负载

内容的提问来源于stack exchange，提问作者Rado Buransky