fren
Log In

Understand resource limits

3 min read07 November 2026

A Python application does not only fail because of a bug. It can run out of memory, be slowed by a CPU limit, or be unable to write to disk. Telling these three cases apart prevents random plan upgrades.

1. Three resources, three symptoms

Resource Typical symptom Measurement
RAM process killed, exit code 137, MemoryError free -m, ps, memory.events
CPU slow responses, timeouts, growing queue top, ps, response time
Disk write failures, corrupted database, interrupted logs df -h, du

An application may use little on average and a lot at peak: importing a large file, generating PDFs, a query without pagination. Size for the peak, not for idle.

2. Measure and recognize exhaustion

On a Debian VPS, the basic commands:

Bash
free -m
ps -eo pid,comm,%cpu,%mem,rss --sort=-rss | head -n 10
df -h

Inside a system container, cgroup counters show the real limit. On a cgroup v2 system:

Bash
cat /sys/fs/cgroup/memory.max
cat /sys/fs/cgroup/memory.current
cat /sys/fs/cgroup/memory.events

A rising oom_kill counter confirms a process was killed for lack of memory. Exit code 137 means SIGKILL, often sent by the kernel. A CPU limit, by contrast, does not kill the process: requests slow down and timeouts increase, but the service stays alive. On application hosting, the console and panel graphs show usage; a restart after a memory spike is a strong clue.

3. Reduce consumption

  • Stream instead of loading everything: read files in chunks, stream large responses.
  • Paginate: never load a whole table; use LIMIT and OFFSET.
  • Workers: every Python process has its own memory. Four workers cost roughly four times the baseline.
  • Bounded caches: set a maximum size and an eviction policy, or the cache becomes a leak.
  • Logs: rotate them and keep INFO in production.
  • Old data: archive or compress what is no longer read.

Measure before and after every change. Without a baseline, no optimization is verifiable.

4. Choose the plan

VPS plan RAM Reasonable use
Free 512 MB tests, small bot, static site
Basic 2 GB light API, one Python service
Pro 4 GB several services, local database
Business 8 GB heavier load, multiple workers

On application hosting, resources depend on the selected plan. Compare on the pricing page and keep headroom: a temporary spike must not trigger an OOM.

5. Verify

  1. Record usage at idle, then under real load.
  2. Check memory.events after a day of traffic.
  3. Test the heaviest scenario before paying for an upgrade.
  4. Watch disk space: logs and temporary files are the first suspects.

Advertisement

Was this article helpful?

Read next