How should I choose worker counts and memory limits for a server application?
There is no safe universal rule to allocate every core or all RAM to one application. More workers can improve throughput until memory, CPU, storage or external dependencies become the bottleneck. Set limits using measured per-worker demand, peak traffic and the application’s documented concurrency model.
Before you start
- An authorised SSH session on the Linux server.
Instructions
1. Measure the available environment
Record CPU topology and memory before a representative workload test. On a VPS or container, also inspect quotas and provider allocation rather than assuming displayed topology is unrestricted capacity.
lscpu
free -hThese establish capacity context, not a recommended worker count. Reserve room for the kernel, caches, monitoring and other required services.
2. Compare pressure and service outcomes
Where PSI is available, observe resource stalls during controlled load. Change one application setting at a time and compare latency, throughput, errors and memory growth.
cat /proc/pressure/cpu
cat /proc/pressure/memory
cat /proc/pressure/ioPressure trends help identify the constrained resource. They should be paired with application metrics and the relevant cgroup limits.
Check the result
- The selected concurrency meets response-time and throughput goals under expected peaks without OOM kills, sustained swapping or uncontrolled queue growth.
Troubleshooting
- More workers make performance worse
- Contention, memory multiplication or backend saturation may dominate. Revisit the measured bottleneck and the previous tested setting.
- A development test looks faster
- Production data volume, concurrency and external latency may differ; validate against representative conditions.
Official references
Use the documentation for your installed version when a flag, service name or platform feature differs.