Cassandra

Thread Pool Saturation Causing Backpressure

warning
Resource ContentionUpdated Apr 18, 2025

When Cassandra's internal thread pools (read, mutation, request, compaction) become saturated with blocked tasks, new requests queue up or fail despite available system CPU. This creates latency spikes before visible service degradation.

How to detect:

Use nodetool tpstats to detect high values in 'pending tasks' and 'currently blocked tasks' columns across read/write thread pools. Correlate with rising cassandra_thread_pool_count_blocked_tasks and cassandra_thread_pool_currently_blocked_tasks. Watch for cassandra_client_request_read_time_50p and write latency percentiles increasing despite low CPU utilization.

Recommended action:

Increase concurrent_reads and concurrent_writes in cassandra.yaml if system resources permit (monitor CPU and context switching). Review query patterns for inefficient scans using ALLOW FILTERING. Check if compaction or repair operations are starving request threads. Consider increasing native_transport_max_threads if client connections are the bottleneck. Scale horizontally if saturation persists.