https://adminsforum.com/ Thu, 15 Oct 2026 04:28:39 +0000 MyBB https://adminsforum.com/Thread-guide-high-linux-memory-usage-cache-swap-and-oom-troubleshooting Thu, 08 Oct 2026 03:11:59 +0800 DEV]]> https://adminsforum.com/Thread-guide-high-linux-memory-usage-cache-swap-and-oom-troubleshooting Low “free” memory is not enough to diagnose a Linux memory problem. Look for available memory, sustained swapping, pressure and evidence of a killed process before changing limits.

1. Capture the symptom and baseline
Note whether the site is slow, an application exited or the whole VPS becomes unresponsive. On a systemd Linux server:

Code:Copy

free -h uptime vmstat 1 5 ps -eo pid,user,comm,rss --sort=-rss | head -n 15 sudo journalctl -k --since "1 hour ago" --no-pager

The first vmstat report reflects averages since boot; compare the later samples. RSS is in KiB in this ps format and shared memory can be counted across processes, so summing RSS is only a rough estimate. Avoid posting full process arguments, which can contain credentials.

2. Distinguish useful cache from pressure
Linux uses otherwise idle memory for filesystem cache. The available estimate is more useful than free alone. Swap in use may remain after an earlier spike; sustained swap-in/out with latency is more concerning. Check the workload over time, including backups, imports and scheduled jobs.

Do not routinely drop kernel caches to make a dashboard greener. It can increase disk reads and hide the real workload. Compare symptoms with memory pressure, process growth and application logs instead.

3. Investigate OOM and container limits
Kernel logs may identify an out-of-memory kill and the selected process. A container or systemd cgroup can reach its own limit even when the host has spare memory. Inspect the relevant service/container memory limit and restart history. systemd-oomd can also terminate workloads based on pressure; inspect its journal when present.

A database, PHP pool and background workers share the same VPS. Raising every concurrency setting at once can exhaust it. Find the time-correlated change: plugin deployment, traffic surge, import, larger database cache or leak.

4. Choose a measured correction
Reduce excessive workers, bound caches, stagger heavy jobs or optimize the expensive request. If memory grows steadily under a repeatable workload, investigate a leak before using scheduled restarts as a permanent solution. Leave headroom for updates, backups and spikes.

Swap can provide a safety cushion on supported filesystems, but disk-backed memory is slower and does not create more physical RAM. Confirm provider/filesystem support and existing swap/zram before adding another mechanism. Never run swapoff on a pressured production system without enough RAM to hold the swapped pages.

5. Test and monitor
Change one setting during a maintenance window, preserve the previous configuration and compare response time, errors, available memory and swapping under similar load. Observe long enough to catch recurring jobs. An absence of OOM messages alone does not prove performance is healthy.

Useful report: OS, RAM plan, container limits, affected service, baseline samples and sanitized OOM lines. Do not publish environment dumps or process command lines containing secrets.

References: Your installed man free, man vmstat and systemd resource-control documentation; PHP-FPM pool configuration for PHP workloads.]]> Low “free” memory is not enough to diagnose a Linux memory problem. Look for available memory, sustained swapping, pressure and evidence of a killed process before changing limits.

1. Capture the symptom and baseline
Note whether the site is slow, an application exited or the whole VPS becomes unresponsive. On a systemd Linux server:

Code:Copy

free -h uptime vmstat 1 5 ps -eo pid,user,comm,rss --sort=-rss | head -n 15 sudo journalctl -k --since "1 hour ago" --no-pager

The first vmstat report reflects averages since boot; compare the later samples. RSS is in KiB in this ps format and shared memory can be counted across processes, so summing RSS is only a rough estimate. Avoid posting full process arguments, which can contain credentials.

2. Distinguish useful cache from pressure
Linux uses otherwise idle memory for filesystem cache. The available estimate is more useful than free alone. Swap in use may remain after an earlier spike; sustained swap-in/out with latency is more concerning. Check the workload over time, including backups, imports and scheduled jobs.

Do not routinely drop kernel caches to make a dashboard greener. It can increase disk reads and hide the real workload. Compare symptoms with memory pressure, process growth and application logs instead.

3. Investigate OOM and container limits
Kernel logs may identify an out-of-memory kill and the selected process. A container or systemd cgroup can reach its own limit even when the host has spare memory. Inspect the relevant service/container memory limit and restart history. systemd-oomd can also terminate workloads based on pressure; inspect its journal when present.

A database, PHP pool and background workers share the same VPS. Raising every concurrency setting at once can exhaust it. Find the time-correlated change: plugin deployment, traffic surge, import, larger database cache or leak.

4. Choose a measured correction
Reduce excessive workers, bound caches, stagger heavy jobs or optimize the expensive request. If memory grows steadily under a repeatable workload, investigate a leak before using scheduled restarts as a permanent solution. Leave headroom for updates, backups and spikes.

Swap can provide a safety cushion on supported filesystems, but disk-backed memory is slower and does not create more physical RAM. Confirm provider/filesystem support and existing swap/zram before adding another mechanism. Never run swapoff on a pressured production system without enough RAM to hold the swapped pages.

5. Test and monitor
Change one setting during a maintenance window, preserve the previous configuration and compare response time, errors, available memory and swapping under similar load. Observe long enough to catch recurring jobs. An absence of OOM messages alone does not prove performance is healthy.

Useful report: OS, RAM plan, container limits, affected service, baseline samples and sanitized OOM lines. Do not publish environment dumps or process command lines containing secrets.

References: Your installed man free, man vmstat and systemd resource-control documentation; PHP-FPM pool configuration for PHP workloads.]]>