Cómo resolver el uso elevado de memoria en Linux

Shared FAQ page chrome: see INDEX-AND-CHROME.md. Translate once.

Body

Cómo averiguar qué está consumiendo la memoria de un servidor Linux, y los ajustes de overcommit del kernel que lo controlan.

Identificar el escenario «Out of Memory».

Puede que la presión ya haya pasado cuando usted mire, así que compruebe primero en el log del kernel si ha habido OOM kills: el kernel de Linux gestiona la memoria del servidor matando tareas o procesos según ciertos criterios y liberando la memoria que ocupaba el proceso terminado.

Por cada proceso que el kernel termina así se genera una entrada de log, y los logs suelen estar en /var/log/.

Puede usar el comando grep siguiente para buscar un error de falta de memoria en todos los archivos de log de /var/log/.

grep -i -r 'out of memory' /var/log/
Mar 1 01:24:05 srv kernel: [3966348.114233] Out of memory: Kill process 48305 (php-cgi) score 21 or sacrifice child
Mar 1 01:24:08 srv kernel: [3966350.061954] Out of memory: Kill process 48318 (php-cgi) score 21 or sacrifice child

Uso actual:

root@srv:~# free -m 
              total        used        free      shared  buff/cache   available
Mem:     1981         720         319         138         940         916
Swap:      524          84         440

El histórico de uso de memoria del día puede verse con el comando «sar».

root@server [~]# sar -r
Linux (server.example.com)       03/05/2019      _x86_64_        (2 CPU)
12:00:01 AM kbmemfree kbmemused  %memused kbbuffers  kbcached  kbcommit   %commit
12:10:01 AM   1672764   1407160     45.69    100356    749140   1618364     44.90
12:20:01 AM   1289208   1790716     58.14    106580   1130096   1599588     44.38
12:30:01 AM   1248100   1831824     59.48    109184   1144680   1621332     44.98
12:40:01 AM   1267972   1811952     58.83    111460   1155828   1604104     44.51
12:50:01 AM   1254556   1825368     59.27    113888   1159632   1599480     44.38
01:00:01 AM   1092296   1987628     64.53    116020   1164540   1802228     50.00
01:10:01 AM   1212168   1867756     60.64    118204   1169516   1633940     45.33
...
Average:    kbmemfree kbmemused  %memused kbbuffers  kbcached  kbcommit   %commit
Average:      1465222   1614702        52.43          179213    834889      1655342     45.93

Es necesaria una ampliación de RAM si el servidor muestra un uso de memoria alto de forma constante o si el uso medio del día supera el 90 %, porque un uso tan alto puede agotar por momentos la memoria libre de un servidor con carga. En una máquina virtual, la presión de memoria sostenida se resuelve con más RAM o corrigiendo la aplicación, nunca con swap.

Otra herramienta útil para identificar los procesos que consumen memoria es el comando «top», que permite ordenar los procesos en ejecución por su uso de recursos.

root@server [~]# top -c
top - 18:41:45 up 109 days, 18:03,  5 users,  load average: 1.30, 1.24, 1.24
Tasks: 544 total,   2 running, 541 sleeping,   0 stopped,   1 zombie
Cpu(s):  8.3%us,  1.4%sy,  0.2%ni, 89.8%id,  0.3%wa,  0.0%hi,  0.1%si,  0.0%st
Mem:  12296096k total, 11531800k used,   764296k free,   586732k buffers
Swap: 16777212k total,   209160k used, 16568052k free,  2471072k cached
    PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                                                    
2376001 root      20   0  230m 101m 4588 R 31.4  0.8   1:22.06 spamd child                                                                                                                 
2448741 root      30  10 19472 1056  792 S  2.6  0.0   0:00.08 /usr/sbin/lveps -c 1 -p -d -n -o id:10,ep:10,pno:10,pid:15,tno:5,tid:15,cpu:7,mem:15,com:256                                
 953572 mysql     20   0 17.5g 5.3g 5336 S  1.7 44.9 102:38.10 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/mysql/plugin --user=mysql --log-error=server
 844549 root      30  10  424m  59m 4532 S  1.3  0.5  52:13.20 /opt/alt/python27/bin/python2.7 /usr/share/lve-stats/lvestats-server.py start --pidfile /var/run/lvestats.pid               
1351883 root      20   0 1127m 638m 1768 S  1.3  5.3  37:37.24 /usr/local/cpanel/3rdparty/bin/clamd                                                                                        
 844526 root      30  10  462m  35m 1204 S  1.0  0.3  30:54.20 /opt/alt/python27/bin/python2.7 /usr/share/lve-stats/lvestats-server.py start --pidfile /var/run/lvestats.pid               
   3109 nscd      20   0 2725m 3956 2260 S  0.7  0.0 188:08.43 /usr/sbin/nscd                                                                                                              
2243573 nobody    20   0  189m  78m 1140 S  0.7  0.7   4:22.20 litespeed (lshttpd - #01)                                                                                                   
2448384 mailnull  20   0 78756 7736 3348 S  0.7  0.1   0:00.06 /usr/sbin/exim -bd -q1h -oP /var/spool/exim/exim-daemon.pid

Puede seguir esta secuencia de teclas para ordenar los procesos por uso de memoria.

Ejecute el comando top. Pulse SHIFT+o para ver las opciones del comando top. Pulse N e Intro.

Identificar fugas de memoria

Puede localizar la hora del servidor a la que se registró el «out of memory»; aquí es “Mar 1 01:24:05”. Use el comando grep para buscar esa marca de tiempo en los archivos de log de sus servidores de aplicaciones, como Apache, MySQL, etc.

En un servidor cPanel, puede usar grep sobre los logs de acceso del sitio web para detectar accesos sospechosos o abusivos que hayan causado el agotamiento de recursos.

grep  -ir “01/Mar/2019:01:2”  /usr/local/apache/domlogs/

Algunas actividades sospechosas que se identifican en los logs de acceso son:

1. Muchos accesos desde direcciones IP concretas.
2. Muchos accesos a recursos o archivos inexistentes, etc.
3. Un número alto de peticiones HTTP POST.
4. Un número alto de intentos de acceso fallidos, como inicios de sesión.

Use el comando mysqladmin proc stat para identificar consultas MySQL colgadas durante mucho tiempo que estén provocando un uso alto de memoria.

root@server [~]# mysqladmin proc stat
+--------+------+-----------+----+---------+------+-------+------------------+----------+
| Id     | User | Host      | db | Command | Time | State | Info             | Progress |
+--------+------+-----------+----+---------+------+-------+------------------+----------+
| 137324 | root | localhost |    | Query   | 0    | init  | show processlist | 0.000    |
+--------+------+-----------+----+---------+------+-------+------------------+----------+
Uptime: 370827  Threads: 1  Questions: 20484133  Slow queries: 0  Opens: 1456  Flush tables: 1  Open tables: 747  Queries per second avg: 55.239

Revise las columnas Time, db y State, localice las consultas con un valor alto en «Time» y revíselas con el desarrollador de su sitio web.

Active el «registro de consultas lentas» en MySQL y corrija las consultas largas con el desarrollador de su sitio web.

Overcommit de memoria

Normalmente, el servidor Linux permite reservar para un proceso más memoria de la que realmente necesita, partiendo de la suposición de que ningún proceso usará toda la memoria que se le permite, y esa memoria puede aprovecharse para otros procesos. Se puede configurar cómo gestiona el sistema Linux el overcommit de memoria, y la configuración se aplica con la utilidad sysctl.

Todos los parámetros de control de sysctl se listan con el comando sysctl -a, y el parámetro que nos interesa es vm.overcommit_memory.

[root@srv ~]# sysctl -a | grep vm.overcommit_memory
vm.overcommit_memory = 0

vm.overcommit_memory puede tener 3 valores: 0, 1 y 2.

• 0 Permite el overcommit según la estimación «si tenemos RAM suficiente»
• 1 Permite siempre el overcommit
• 2 Deniega el overcommit si el sistema no tiene la memoria

Otro parámetro de sysctl a tener en cuenta es overcommit_ratio, que define qué porcentaje de la memoria física, además del espacio de swap, se puede considerar al permitir el overcommit de los procesos.

Supongamos que ponemos vm.overcommit_memory a 2: el kernel no permitirá un overcommit que supere el espacio de swap más el vm.overcommit_ratio de la RAM total. vm.overcommit_memory=2 vm.overcommit_ratio=50% RAM=8GB SWAP=4GB

Con la configuración anterior, el overcommit posible es 4GB de SWAP + el 50 % de 8GB de RAM.

sysctl -w vm.overcommit_memory=2
sysctl -w vm.overcommit_ratio=100

sysctl -w no sobrevive a un reinicio; ponga las mismas dos líneas en /etc/sysctl.conf.