Out of memory (OOM) and memory pressure

Recognise and resolve out-of-memory conditions and swap thrashing on your TurboStack host.

When a host runs out of RAM, the Linux kernel's OOM killer terminates whichever process it considers least essential to free memory. The result is unpredictable: a database, a PHP worker, or a cache may be killed mid-request. TurboStack gives you the tools to spot memory pressure early and to right-size the services that consume it.

Symptoms

Processes disappear or restart on their own (the kernel "OOM-killed" them).
Swap usage climbs and stays high, and the whole host feels sluggish - a sign the server is paging memory to disk to stay alive.
Intermittent 5xx errors as PHP workers or the database are killed and restarted (see Fixing 502, 503 and 504 errors).
Database connections drop, or MySQL/PostgreSQL restarts unexpectedly.

Diagnose it on TurboStack

Start on the host's Health tab:

The RAM and Memory swap cards show current usage and an OK/Warning/Critical status. Use the 1H / 8H / 1D / 7D range buttons to see whether pressure is constant or spikes at certain times (for example during a cron run or traffic peak). Sustained high swap is the clearest sign of memory pressure.
Top issues ranks detected problems by severity and category - a memory or stability issue here usually names the service involved and a recommended fix.
Latest reports holds the investigation reports for the host. Open the most recent one to see whether memory or swap was already flagged.

Tip

Look here before you connect over SSH. When a host is under memory pressure, Top issues and Latest reports often report it already, as a PERFORMANCE or STABILITY issue about memory or swap. That tells you which service is consuming the memory before you go looking yourself.

Check whether a recent change is responsible. Open the host's History (Revisions / Deploys) to see if a recent publish raised a worker count or a sizing key; if so, you can roll back.

For a live view, connect to the host over SSH with your own SSH client, using a key that is listed on the host's SSH tab. Inspect per-process memory, then check the kernel log for OOM-killer events:

free -h                       # total, used and free memory and swap
ps aux --sort=-%mem | head    # top processes by memory use
journalctl -k | grep -iE 'oom|out of memory'   # OOM-killer events

Common causes and fixes

Important

Memory sizing on TurboStack is auto-tuned to your server. Change a sizing key only with measured evidence, and apply the smallest increase that relieves the pressure. Guessing at larger values commonly makes things worse. See Performance tuning.

PHP `memory_limit` and too many workers

Total PHP memory is roughly memory_limit multiplied by the number of PHP-FPM workers. A high memory_limit is usually fine on its own, but combined with many concurrent workers it can exhaust RAM under load.

Right-size memory_limit to what the application actually needs - see How to override PHP settings.
Review the PHP-FPM process-manager limits (max/spare workers) so concurrency matches available memory; see Performance tuning. Raise worker counts only when you have the headroom.

Database buffer pool / shared buffers too large

The database keeps a large in-memory cache. If it is sized too aggressively for the host, it competes with PHP and the OS for RAM. With evidence (sustained pressure traced to the database), adjust the relevant sizing key:

Key	Engine
`mysql_innodb_size`	MySQL InnoDB buffer pool
`postgresql_shared_buffers`	PostgreSQL shared buffers
`redis_memory`	Redis maximum memory before eviction

These are documented in Performance tuning. Apply changes in the TurboStack Platform (GUI or Source) and publish.

Too many processes competing for RAM

Several memory-hungry services on one host (database, Redis, Elasticsearch, Varnish, plus PHP workers) can add up to more than the host has. Confirm the biggest consumer on the Health tab or over SSH, then either reduce that service's allocation or reduce concurrency elsewhere rather than raising everything at once.

The host has genuinely outgrown its plan

If usage is legitimate - traffic and data have grown, and every service is already right-sized - the host simply needs more RAM. Upgrade the plan from the Customer Center, or talk to sales to choose a larger host.

Prevent it

Treat the auto-tuned defaults as the baseline; override only with evidence and re-measure after each change - see Performance tuning.
Keep memory_limit realistic and worker counts in line with available RAM.
Watch the RAM and Memory swap cards on Health and the fleet Monitoring dashboard so you catch a rising trend before it becomes an outage.

When to contact support

Contact Support if the host keeps hitting OOM after right-sizing, if you need to scale the plan, or if a managed service is being killed and you cannot see why. Include the host, the affected domain, what changed recently, and the time of the OOM event so the log can be correlated.