The lack of free free in Linux alone is not a problem; the operating system consumes unused RAM to cache files and retrieves them if needed. The problem is serious when available memory is steadily declining, swap and latency are increasing, processes are uncontrolled, or the OOM Killer service is shut down.
Quick answer:Instead of a snapshot, see the available time, swap, and RSS process trends. Divide the consumption between PHP-FPM, MySQL, Redis, Web server, and CLI jobs. Then calculate the concurrency and ceiling of each process with real RAM; restart will only temporarily clear the graph.
The system RAM is different from PHP's memory_limit.
memory_limitThe roof is a PHP processing unit, but multiple workers can use memory simultaneously. MySQL buffers, Redis, kernels, and other services also share. A request may reach the roof of PHP while the server RAM is free, or conversely, the total workers can reach the system to the OOM without any of them reaching the individual roof.
For the PHP individual error,The PHP memory run-out guideThis article focuses on the total server capacity.
How do we read the free numbers?
free -h
vmstat 1
ps -eo pid,ppid,cmd,rss,%mem --sort=-rssThe door.freeThe available column is more useful than the free raw.vmstatThe swap shift and momentum pressure is shown andpsIt lists major processes. These tools are read-only; take a few samples at a time of trouble and delete sensitive command line information before you share.
A sign of real memory stress.
- Continuous increase in swap-in/swap-out and a noticeable slowdown
- Record OOM or killed process in kernel log
- Restarting PHP-FPM, MySQL or container
- RSS growth is a process without a return after the end of the workload
- Request line and timeout simultaneously with drop available memory
- Backup, import or large-scale job error
Why does PHP-FPM take up so much RAM?
Each worker keeps the code, extension, and data requested. The number of workers, type of process manager, variety of workloads, and peak consumption are determinants. Capacity estimates should be made with RSS of real samples at normal and heavy load; simply multiplying a theoretical ceiling on the number of workers is conservative, but ignoring concurrency is also dangerous.
They're up.pm.max_childrenIt may shorten the queue but run out of RAM. Extreme lowering also keeps requests in the queue. Controlled worker recycling can limit the growth caused by some libraries, but does not treat leakage or code spending.
MySQL and memory.
Part of the RAM database is intentionally used for buffer pool and caches. This can be useful and increase its unnecessary reduction in I/O. In contrast, buffers per-connection, multiple connection, and sort/join queries can grow with concurrency. Do not configure MySQL separately from PHP; both use the same host RAM.
If the query, lock or schema is wrong,MySQL and WordPress error guidesThe increase in RAM does not replace the correct index or query.
Redis and Object Cache
Redis is designed to store data in memory; so its RAM consumption is not an error in itself. The problem is when the eviction policy, memory ceiling, TTL or namespace is not appropriate. Redis sharing between multiple sites without proper separation also risks collision or other service data leakage.
The object cache should not store data without limitation or very large objects. Measure hit rate, large keys, and eviction.
Command line jobs and big processing
Backup, import, thumbnail generation, scan, and export may be run outside the web pool. So the PHP-FPM dashboard does not show all consumption. See process tree, cron, and side containers. Batch the job and avoid overlap; re-executing the job transaction should be checked for idempotency.
The process of diagnosis
- Extract the time and pattern of RAM growth from the monitoring.
- Group RSS by service and process.
- Apply traffic, cron, backup and deployment to the same area.
- Check swap, OOM and restart in the system log.
- For PHP, profile the endpoint and peak request in staging.
- For MySQL and Redis, separate useful caches from ceilingless growth.
- After the change, measure the available memory, latency and error rate again.
Low-risk prevention of the accident.
If the OOM is close, first stop the non-living and specified job, add malicious traffic to the targeted limited or temporary capacity. A random MySQL kill or swap file deletion can cause complete and damaged data. Save the process and logs before restarting and have a service return program.
Common Mistakes
- Judging from the free column regardless of available and cache
- A periodic restart instead of finding the growth trend
- Increase worker time and memory_limit
- The database buffer is reduced without I/O measurement.
- Redis is being cleared on schedule.
- Ignoring CLI and backup processes
Prevention of the disease
Create RSS services and restart alerts for available memory, swap, OOM, and restart. Test capacity with peak traffic and concurrent jobs. Compare large backup and import in the appropriate run and deployment window with baseline resources. Leave a safe margin for kernels and spikes.
When do you need special assistance?
If consumption continues to grow, OOM shut down services, or PHP and MySQL configurations have affected each other, repeated restarts increase the risk of a definite.WordPress speed boost serviceIt can model the actual capacity and source of RAM usage.
Common Questions
Is the RAM almost full on Linux bad?
Not necessarily; the system cache is useful. Check for available, swap, reclaim and latency.
Does adding RAM solve the problem?
It's useful for real capacity, but leak, job and infinite adjustment only reveal later.
Why does it decrease and return after restarting?
The caches are re-heated or workload/leak repeated; the process and process factor must be specified.