How to Find and Fix a Memory Leak on a Linux Server

A memory leak is a situation where a process continues to occupy RAM even though the data it uses is no longer needed. Over time, memory consumption may increase, leading to reduced server performance, the OOM Killer being triggered, individual services being stopped, and in some cases applications becoming completely unavailable.
On a Linux server, increasing memory consumption can be caused by an error in a specific application, incorrect service configuration, too many processes, or high system load.

How to Determine Whether There Is a Memory Problem on the Server

The first sign is a gradual increase in used RAM.
You can check the overall memory status with:
free -hFor example:


Pay particular attention to the available value. The free value alone does not mean that the server is running out of memory: Linux uses free RAM for caching.
If available memory is constantly decreasing, swap is being actively used, and memory consumption continues to grow, you need to find the process that is consuming RAM.

How to Find the Process Using the Most Memory

For a quick overview of running processes, you can use:
top

In top, press: Shift + M
The processes will then be sorted by memory usage.


You can also immediately display the processes with the highest memory consumption:
ps aux --sort=-%mem | head -20The command will show the first 20 processes with the highest RAM consumption.
For example:


At this stage, it is important to determine not only which process is using the most memory, but also how its memory consumption changes over time.
A large process is not necessarily the cause of a memory leak. For example, a database may be configured to use several gigabytes of RAM and operate normally.

What Are RSS, VSZ, and %MEM?

When analyzing ps and top, you may encounter several memory-related metrics.
RSS (Resident Set Size) is the amount of physical RAM currently used by a process.
VSZ (Virtual Size) is the total amount of virtual address space allocated to a process. It can be significantly larger than the amount of RAM actually being used.
%MEM is the percentage of the server's physical RAM used by the process.
When looking for memory leaks, it is particularly useful to monitor RSS.
For example, if the same process gradually increases its RSS:
200 MB
350 MB
600 MB
900 MB
1.5 GB
2.5 GB
and its memory consumption does not return to its previous level, this may indicate a memory leak.

How to Check the Memory Usage of a Specific Process

For more detailed information, you can inspect /proc.
For example, for a process with PID 1020:
cat /proc/1020/status

Pay attention to the following parameters:
VmSize:
VmRSS:
VmData:
VmSwap:
The most important one is:
VmRSS
It shows the amount of physical memory currently used by the process.
You can also view the process's memory map:
cat /proc/1020/smapsHowever, smaps contains a large amount of information, so for initial diagnostics, top, ps, and /proc//status are usually sufficient.

How to Determine Whether Memory Is Actually Being Gradually Consumed

A single check is not enough.
If the problem occurs after several hours or days, you need to monitor the process over a certain period of time.
For example:
watch -n 10 'ps -o pid,ppid,%mem,rss,vsz,cmd -p 1020'

The command will update the information every 10 seconds.
If the process's RSS constantly increases:
200 MB
350 MB
620 MB
750 MB
900 MB
this is a reason to investigate the application in more detail.
For long-term monitoring, you can periodically record the metrics to a log or use server monitoring systems.

Not Every Increase in Memory Usage Is a Memory Leak

It is important to distinguish a memory leak from normal application behavior.
For example, Linux actively uses RAM for the file cache. Therefore, the output of:
free -hmay show a small amount of free memory even on a normally functioning server.
Some applications also intentionally use caching.
For example, a database may gradually consume more memory after startup and then stabilize.
Therefore, high RAM usage alone does not mean that there is a memory leak.
The main sign of suspicious behavior is an unlimited or constantly growing amount of memory used by a single process or group of processes without a corresponding increase in workload.

Checking Swap

If there is not enough physical RAM, Linux starts using swap.
Check its usage with:
free -hor:
swapon --showActive swap usage may indicate insufficient RAM, but by itself it does not prove that there is a memory leak.
If swap is constantly filling up, you need to determine which process is consuming memory and why.

How to Find the OOM Killer

If the system runs completely out of memory, Linux may start the OOM Killer (Out Of Memory Killer). It selects processes and forcibly terminates them to free memory.
You can check kernel messages with:
dmesg -T | grep -i -E 'oom|out of memory|killed process'On systems using systemd, you can also use:
journalctl -k | grep -i -E 'oom|out of memory|killed process'For example:
Out of memory: Killed process 2212 (php-fpm)

This means that the kernel terminated the php-fpm process because the system ran out of memory.
In this case, you need to determine why the memory was exhausted. Simply increasing the amount of RAM does not always solve the problem.

Checking the Number of Processes

Sometimes the problem is not caused by a single memory leak, but by a large number of processes.
For example, a server may create hundreds or thousands of PHP-FPM, Apache, or other service processes.
Check the total number of processes with:
ps aux | wc -l

To count processes belonging to a specific user:
ps -u www-data | wc -l

For PHP-FPM:
pgrep -c php-fpm

If the number of processes is constantly increasing and does not return to a normal level, you should check the service configuration.
For PHP-FPM, important parameters include:
pm.max_children
pm.max_requests
pm.max_spare_servers
pm.min_spare_servers
A value of pm.max_children that is too high can cause a large number of PHP processes to consume all available RAM simultaneously.

The pm.max_requests Parameter

The pm.max_requests parameter limits the number of requests that a PHP-FPM worker processes before being restarted.
For example:
pm.max_requests = 500
This can be useful if a specific PHP application or extension gradually increases memory consumption.
After processing the specified number of requests, the worker is terminated and a new one is created.
It is important to understand that pm.max_requests limits the consequences of a memory leak rather than eliminating its cause. If the leak is located in PHP code or an extension, you need to identify and fix the source of the problem.

How to Check Apache

If Apache is being used, pay attention to the number of simultaneously running processes.
For example:
ps aux | grep apache2

or:
ps aux | grep httpdYou can also check the number of processes:
pgrep -c apache2

A large number of Apache workers can significantly increase RAM consumption.
You should check the MaxRequestWorkers setting, the MPM in use, and the average memory consumption of a single worker.

How to Check MySQL or MariaDB

Databases are often among the largest consumers of RAM on a server.
Check the process with:
ps aux --sort=-%mem | grep -E 'mysql|mariadb'

However, high memory usage by MariaDB or MySQL is not necessarily a problem.
The database uses caches and buffers to improve performance. Therefore, you should analyze its configuration:
mysql -e "SHOW VARIABLES LIKE 'innodb_buffer_pool_size';"

You should also take into account the total amount of RAM available on the server and the memory required by other services.
For example, a server with 16 GB of RAM where the database uses 12 GB while Nginx, PHP-FPM, Redis, and other services are also running may experience insufficient memory even if the database itself is operating normally.

How to Distinguish a Memory Leak from Normal High Load

It is useful to compare memory consumption with the workload.
For example:

Scenario 1:

Number of requests ↑
RAM usage ↑
Number of processes ↑
This behavior may be normal when the workload increases.

Scenario 2:

Number of requests → stable
CPU → stable
RAM → constantly ↑
This is a much stronger indication of a possible memory leak or uncontrolled accumulation of data.

What to Do When a Memory Leak Is Detected

After identifying a suspicious process, you need to determine the source of the problem.
Possible causes include:

• application error;
• faulty PHP or Python extension;
• plugin malfunction;
• large amounts of cached data;
• excessively high process limits;
• service configuration error;
• a long-running process that does not release memory;
• incorrect operation of a third-party module.

If the problem is in your own application, you should use profiling tools and analyze the code.
For PHP, for example, you can use memory profilers and diagnostic tools.
For Python, tracemalloc can be useful, while other programming languages have their own profiling tools.

Temporary Measures

If the memory leak is already causing insufficient memory, the first step is to restore normal server operation.
Depending on the situation, you can:

• restart the problematic service;
• limit the number of worker processes;
• temporarily reduce the workload;
• stop unnecessary services;
• increase the amount of RAM;
• configure swap as an additional protection mechanism.

For example:
systemctl restart php8.3-fpmHowever, restarting a process should be considered a temporary solution. If the cause of the memory leak is not fixed, the problem will occur again.

How to Prevent the Problem from Occurring Again

For servers running critical services, it is recommended to continuously monitor:

• RAM usage;
• swap usage;
• number of processes;
• CPU load;
• disk I/O;
• memory consumption of individual services;
• number of OOM events;
• uptime and service restarts.

It is useful to configure monitoring that stores historical data. This allows you to see not only the current state of the server but also when memory consumption started to increase.

Conclusion

Finding a memory leak on a Linux server should begin not with restarting services, but with analyzing system behavior.
First, check the available memory:
free -hThen identify the processes consuming the most memory:
ps aux --sort=-%mem | head -20After that, monitor the RAM consumption of the specific process and check system logs for OOM events:
journalctl -k | grep -i -E 'oom|out of memory|killed process'The main goal is to determine which process is consuming memory, why its consumption is increasing, and whether this is related to actual workload.
Restarting a service or increasing the amount of RAM may temporarily solve the problem, but with a genuine memory leak, you need to eliminate its source — faulty code, a module, an extension, or an incorrect service configuration.