Caution

You're viewing documentation for an unstable version of ScyllaDB Operator. Switch to the latest stable version.

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