ScyllaDB Performance Tuning

ScyllaDB tunes much of itself. The work that remains is host configuration, keeping shards balanced, and identifying which resource is actually the limit.

Host configuration

scylla_setup                      # interactive: disks, network, NTP, kernel parameters
perftune.py --tune net --tune disks --nic eth0 --mode sq_split
iotune --evaluation-directory /var/lib/scylla    # measures disk, writes io_properties.yaml

iotune benchmarks the storage and records what the I/O scheduler can assume. Skipping it leaves the scheduler working from defaults that may not match the hardware, which shows up as unstable latency under load rather than as an obvious error.

Find the actual limit

curl -s localhost:9180/metrics | grep -E "scylla_reactor_utilization|scylla_io_queue|scylla_transport"

• scylla_reactor_utilization near 100% on some shards only — imbalanced workload; a hot partition or a low-cardinality partition key. Fix the data model, not the hardware. See Hot Partitions.
• All shards near 100% — genuinely CPU bound. Add nodes or cores.
• High I/O queue delays with moderate CPU — storage bound.
• High client-side latency with low server utilisation — the client, the network or connection handling, not the cluster.

Client-side

• Use a shard-aware driver and prepared statements, so requests reach the owning core directly.
• Set a token-aware load balancing policy so the coordinator is also a replica.
• Bound concurrency per client. Unbounded in-flight requests turn a brief slowdown into timeouts across the fleet.
• Set request timeouts shorter than the server's, so the client gives up first and retries with jitter.

Server settings worth reviewing

# scylla.yaml
compaction_static_shares: 100        # relative weight of compaction against user traffic
enable_sstables_mc_format: true
murmur3_partitioner_ignore_msb_bits: 12

Most of scylla.yaml should be left alone. The exceptions are timeouts, which should reflect your latency objectives:

read_request_timeout_in_ms: 5000
write_request_timeout_in_ms: 2000
range_request_timeout_in_ms: 10000

A timeout longer than the client's is wasted work — the client has already given up.