I have a Quarkus and GraalVM native Kubernetes operator with a 300m CPU limit. Average CPU usage is only about 13% of that limit, but the throttled periods metric keeps increasing.
There are roughly 130 live threads, though most Vert.x workers appear idle. ActiveProcessorCount barely changed the thread count, and reducing the worker pool to eight did not change the throttling. What else should I check before raising or removing the CPU limit?
Low average usage can hide short bursts. With a 100 ms CFS period, a 300m limit typically gives the container 30 ms of CPU time per period. If several runnable threads use that budget quickly, the container can be throttled for the rest of the period even though its longer-term average looks small.
The number of live threads alone doesn't establish that this is happening. Idle threads don't consume a CPU quota just by existing. Look at throttled periods alongside throttled time, CPU usage at the finest resolution available, and application latency. That should help distinguish a harmless-looking counter from throttling that is actually affecting the operator.
Since shrinking the Vert.x pool didn't change throttling, I wouldn't keep treating its configured size as the smoking gun. It may still be worth keeping the smaller pool if it handles the workload, but check for queued work and slower reconciliations before settling on the value.
Next I'd identify which threads are actually runnable during bursts, including the operator SDK executors and native runtime threads. Thread dumps or profiling around a throttling event would be more useful than another snapshot of the live thread count.
Try a higher CPU limit, or no CPU limit if your cluster policy allows it, and compare throttling and latency under similar load. A CPU request and a limit do different jobs. A low request can coexist with room to burst, while a low limit caps that burst.
Removing limits is a tradeoff, not a universal fix. Consider contention with other workloads and your cluster's resource policies before changing it.
I'd be cautious about assuming HotSpot flags have the same effect on a native image. The ActiveProcessorCount experiment didn't reduce the threads here and coincided with health-check trouble, but that doesn't prove a general rule about which settings are baked in.
Check the GraalVM and Quarkus documentation for the exact versions and native runtime options in use. Test build-time and runtime changes separately, and verify the resulting behavior rather than relying on JVM-only tests.
First decide whether this is causing a problem. A throttled-periods counter rising by itself doesn't tell you how much delay the application experiences. If reconciliation times and health checks are fine, it may not be worth chasing a lower counter at the expense of reliability.
Answers are reviewed before publication.
Jexmar-3p:
Check the actual CFS quota and period too. The 100 ms period is a common default, not something to assume for every setup.