Start with the host capacity
Docker containers do not receive resource limits by default. Memory and CPU controls can constrain workloads, but the choice of limits affects behaviour under pressure. A memory limit can result in a process being killed; CPU constraints can make work take longer. Read the controls for the runtime you actually deploy.
Create a host worksheet that lists physical or assigned capacity, expected workloads, monitoring overhead and reserved headroom. Do not allocate every byte to application containers. The host and supporting services need capacity too.
Observe ordinary and busy periods
Collect a baseline during a representative workload rather than immediately after startup. Include a scheduled job or import if it is part of normal operation. Record the input size, request pattern and software version beside the observation.
For example, a publication may serve pages cheaply but use much more memory while rebuilding its search index. Treat that job as part of the workload. If it shares the same host as a database, the overlap matters more than either service’s quiet-period average.
Test a limit as a failure condition
Apply changes in a test environment first. Observe how the application behaves when it reaches the budget: does it slow down, restart or return errors? A limit without an understood failure mode simply moves the incident.
Document the chosen limit, why it exists, and the signal that would justify revisiting it. Pair the setting with an alert or review process that someone owns. Recheck after meaningful workload changes; a budget is an operating assumption, not a permanent fact.
Before you finish
- Host headroom reserved
- Batch jobs included in the baseline
- Failure behaviour observed
- Budget owner recorded
Technical reference
Docker: resource constraints