Container Out of Memory
A container that exceeds its memory limit is killed and restarted. Under sustained load this shows up as replicas cycling and intermittent errors. The fix is either more memory or less memory pressure in the application.
Updated 3 Aug 20262 min read
A container that exceeds its memory limit is killed and restarted. Under sustained load this shows up as replicas cycling and intermittent errors. The fix is either more memory or less memory pressure in the application.
Symptoms
- The container restarts under load, or at semi-regular intervals as memory builds up.
- Requests intermittently fail with 5xx errors while a replica is being restarted.
- Memory usage climbs steadily and the container is killed when it reaches its limit.
Likely causes
- The memory limit is too low for the application's normal working set.
- A memory leak — usage grows over time and never comes back down until a restart.
- A load spike pushes a normally-fine application over its limit briefly.
- A large in-memory operation — loading a big dataset, buffering an upload, or an unbounded cache — allocates more than the limit allows.
How to fix
- Check actual usage. Compare the container's memory usage against its configured limit to see how much headroom you have. If you expose Prometheus metrics, they show process memory over time; see Prometheus Metrics.
- Raise the memory limit if usage is genuinely close to the ceiling. With the Reis CLI:
reis container:update <handle> --memory 1024(value in MB). You can also change it in the console. - Investigate a leak if memory only ever climbs. Restarts mask the symptom but not the cause — profile the application to find what isn't being released.
- Handle spikes with autoscaling. Enable autoscaling so extra replicas absorb bursts instead of overwhelming a fixed set. See Resources and Scaling.
- Bound large operations. Stream large payloads instead of buffering them, cap in-memory caches, and page through big datasets rather than loading them whole.
Tip
Memory is billed per region and per replica, so size the limit to your real working set with some headroom — not far above it. Raising the limit fixes an under-provisioned container but only delays the symptoms of a genuine leak.