Dépanner une utilisation mémoire élevée sous Linux

Shared FAQ page chrome (breadcrumb, dates, read time, «Continuer la lecture», enquiry block, category labels): see INDEX-AND-CHROME.md. Translate once.

Body

Comment trouver ce qui consomme la mémoire d'un serveur Linux, et les réglages overcommit du noyau qui la gouvernent.

Identifier la situation « Out of Memory ».

La pression mémoire peut être retombée au moment où vous regardez ; vérifiez donc d'abord les OOM kills dans le journal du noyau : le noyau Linux gère la mémoire du serveur en tuant des processus selon certains critères et en libérant la mémoire occupée par le processus tué.

Une entrée de journal est créée pour chaque processus ainsi terminé par le noyau ; les journaux se trouvent en général dans /var/log/.

La commande grep ci-dessous cherche une erreur out of memory dans tous les fichiers journaux 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

Utilisation actuelle :

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

L'historique de l'utilisation mémoire de la journée s'obtient avec la commande « 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

Une augmentation de RAM s'impose si le serveur affiche une utilisation mémoire élevée en permanence, ou si la moyenne de la journée dépasse 90 % : une telle utilisation peut épuiser par moments la mémoire libre d'un serveur chargé. Sur une machine virtuelle, une pression mémoire durable se règle avec plus de RAM ou en corrigeant l'application, jamais avec du swap.

Un autre outil pratique pour identifier les processus gourmands en mémoire est la commande « top », qui permet de trier les processus en cours selon leur consommation de ressources.

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

Les touches suivantes trient les processus selon leur utilisation mémoire.

Lancez la commande top. Appuyez sur SHIFT+o pour afficher les options de top. Appuyez sur N puis sur Entrée

Identifier les fuites de mémoire

Vous pouvez relever l'heure serveur à laquelle ce « out of memory » a été signalé, ici “Mar 1 01:24:05”. Utilisez grep pour chercher cet horodatage dans les journaux de vos serveurs d'application, Apache, MySQL, etc.

Sur un serveur cPanel, grep dans les journaux d'accès des sites permet de repérer un accès suspect ou abusif au site qui aurait causé cet épuisement des ressources.

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

Quelques activités suspectes identifiables dans les journaux d'accès :

1. Un grand nombre d'accès depuis des adresses IP précises.
2. Un grand nombre d'accès à des ressources ou fichiers inexistants, etc.
3. Un grand nombre de requêtes HTTP POST.
4. Un grand nombre de tentatives d'accès échouées, comme des connexions.

Utilisez la commande mysqladmin proc stat pour identifier les requêtes MySQL qui restent longtemps en attente et consomment beaucoup de mémoire.

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

Regardez les colonnes Time, db et State, repérez les requêtes avec une valeur « Time » élevée et examinez-les avec le développeur de votre site.

Activez le « journal des requêtes lentes » dans MySQL et corrigez les requêtes longues avec le développeur de votre site.

Memory Overcommit

En général, un serveur Linux autorise un processus à réserver plus de mémoire que son besoin réel, en partant du principe qu'aucun processus n'utilisera toute la mémoire qui lui est accordée, le reste pouvant servir à d'autres processus. On peut configurer la façon dont Linux gère cet overcommit mémoire, et la configuration s'applique avec l'utilitaire sysctl.

Tous les paramètres sysctl se listent avec la commande sysctl -a ; celui qui nous intéresse est vm.overcommit_memory.

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

vm.overcommit_memory peut prendre 3 valeurs : 0, 1 et 2.

• 0 Autorise l'overcommit selon l'estimation « si nous avons assez de RAM »
• 1 Autorise toujours l'overcommit
• 2 Refuse l'overcommit si le système n'a pas la mémoire.

Un autre paramètre sysctl à considérer est overcommit_ratio, qui définit quel pourcentage de la mémoire physique, en plus de l'espace de swap, peut être pris en compte pour autoriser les processus à faire de l'overcommit.

Si nous réglons vm.overcommit_memory à 2, le noyau n'autorisera pas un overcommit supérieur à l'espace de swap plus vm.overcommit_ratio de la RAM totale : vm.overcommit_memory=2 vm.overcommit_ratio=50% RAM=8GB SWAP=4GB

Avec la configuration ci-dessus, l'overcommit est possible pour 4GB SWAP + 50% of 8GB RAM

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

sysctl -w ne survit pas à un redémarrage ; mettez les deux mêmes lignes dans /etc/sysctl.conf.