Measure Proxmox API worker pressure before raising the worker count

Bottom line: Measure the request workload before allocating more API workers. Keep the local privileged daemon and the external proxy distinct, and compare any proposed change with a reproducible baseline.

Source fact: what the authority says

The Proxmox pvedaemon manual says the daemon runs as root and exposes the API only at local address 127.0.0.1:85; pveproxy exposes the API externally. By default, pvedaemon starts three worker processes and the manual suggests increasing them for automation-heavy workloads experiencing slow handling or timeouts. The MAX_WORKERS setting is in /etc/default/pvedaemon, and its value must be greater than zero and less than 128. The manual warns that more workers can increase CPU usage and says pveproxy has the same setting.

What the source does not establish

This article covers the documented worker allocation option, not a guaranteed remedy for every slow API request. It does not diagnose a database, network or workload bottleneck, or recommend exposing the local privileged service to external clients.

Applicability questions

• Which automation requests are slow, at what concurrency and at which times?
• What worker settings and CPU observations exist for the current services?
• Does the request reach the intended external proxy and local daemon path?
• What comparison will justify retaining or reversing a proposed increase?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

DSE recommends a workload record with the automation identity, permitted request types, request rate and observed timing. Separate read-only inventory calls from operations that change guests or storage. Keep credentials out of timing logs and avoid increasing production request volume solely to reproduce a delay.

Capture the current daemon and proxy configuration as distinct entries. Identify the service whose worker allocation is proposed for review. Do not copy the manual’s example worker value as a sizing recommendation or assume that increasing both services together will reveal which one influenced the result.

Prepare a bounded read-only test sequence representing the approved automation pattern. Have the system owner set the maximum trial concurrency and stop conditions. Collect request completion observations alongside CPU use and other already available service health evidence before deciding whether a configuration change is warranted.

If an increase is approved, write the selected value and restoration plan into a separate controlled change. Arrange the applicable documented service-management procedure and maintenance precautions before execution. Keep the previous configuration available and do not change client retry behavior at the same time, so the comparison remains interpretable.

Verification and evidence

Proposed verification: run the approved read-only request sequence against the intended endpoint and record completion times, errors and CPU observations for the baseline. Repeat only within the same authorized workload limits after a separately approved worker change. Preserve both successful and timed-out requests in the comparison.

Compare actual request handling and resource use with the prewritten acceptance criteria. Revert through the agreed procedure if the change fails its criteria or introduces unacceptable CPU demand. Report an unresolved delay for further investigation rather than continuing to raise worker counts without identifying the limiting component.

Official references

• Proxmox — pvedaemon(8) — official product documentation; confirm the installed release and configuration.

Source review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.