Troubleshoot performance¶

CPU pinning¶

Diagnose and fix issues with CPU pinning for ScyllaDB Pods.

Check QoS class:

kubectl get pods -l 'app.kubernetes.io/name=scylla' \
  -o=jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.qosClass}{"\n"}{end}'

All ScyllaDB Pods should report Guaranteed.

Check ScyllaDB startup flags — when CPU pinning is active, ScyllaDB starts with --overprovisioned=0:

kubectl logs <pod-name> -c scylla | grep -E 'overprovisioned|smp|cpuset'

Check that the ContainerPerftune Job ran for each ScyllaDB Pod:

kubectl -n scylla-operator-node-tuning get jobs \
  -l scylla-operator.scylladb.com/node-config-job-type=ContainerPerftune

Symptom	Cause	Fix
`qosClass: Burstable`	`agentResources` has no limits, or requests ≠ limits on any container	Set matching requests and limits on both `resources` and `agentResources`
`--overprovisioned=1` in logs	Pod is not Guaranteed QoS, or kubelet lacks static CPU policy	Check QoS class and kubelet configuration
No `ContainerPerftune` job	Pod is Burstable — tuning is skipped for non-Guaranteed Pods	Fix QoS class
`cpuset.cpus.effective` shows all CPUs	Kubelet not using static policy, or CPU request is fractional	Enable `cpuManagerPolicy: static` and use integer CPU values
Latency spikes despite pinning	IRQ affinity not set — perftune job failed or did not run	Verify `NodeConfig` `disableOptimizations` is `false` (default) and check perftune job logs