systemd Utilisation de 4 Go de RAM après 18 jours de disponibilité

14

J'ai un serveur Web exécutant CentOS 7, sur lequel le processus systemd utilise près de 4 Go de RAM après quelques semaines de disponibilité. L'utilisation de la RAM augmente régulièrement à environ 200 Mo par jour. Cela et les processus connexes comme systemd-logind et dbus-daemon utilisent également la plupart du temps un gros morceau de CPU. Mon autre serveur CentOS 6 utilisant "init" au lieu de systemd n'a pas une telle utilisation des ressources.

Dans l'exemple ci-dessous, au cours d'un service Web normal sans autres processus en cours d'exécution, systemd, systemd-logind, systemd-journal et dbus-daemon utilisent un total combiné de 10,7% d'un processeur quadricœur, et systemd consomme 19% du 16 Go de RAM du système. Ce n'est pas un comportement normal et après avoir cherché, je n'ai trouvé personne d'autre avec ce problème. Qu'est-ce qui pourrait causer cette surcharge de ressources? Toute suggestion serait appréciée.

Sortie par le haut pendant une période d'inactivité (sauf pour le service Web):

top - 08:51:31 up 16 days, 13:43,  2 users,  load average: 1.84, 1.39, 1.07
Tasks: 297 total,   2 running, 295 sleeping,   0 stopped,   0 zombie
%Cpu(s):  5.6 us,  3.6 sy,  0.0 ni, 90.6 id,  0.1 wa,  0.0 hi,  0.1 si,  0.0 st
KiB Mem : 16212992 total,  2466564 free,  4275764 used,  9470664 buff/cache
KiB Swap:  4194300 total,  4070740 free,   123560 used. 10707392 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                          
  743 dbus      20   0   27104   1856   1152 S   3.3  0.0 304:27.19 dbus-daemon                                      
    1 root      20   0 3247784 2.920g   1800 S   3.0 18.9 287:41.35 systemd                                          
  737 root      20   0   27416   2524   1304 S   2.7  0.0 225:32.66 systemd-logind                                   
  736 root      20   0  434760   3756   3076 S   2.0  0.0 172:26.53 NetworkManager                                   
  548 root      20   0   82276  34652  34516 S   1.7  0.2 160:20.16 systemd-journal                                  
  770 polkitd   20   0  522920   2956   2248 S   1.7  0.0 120:06.11 polkitd                                          
  716 root      16  -4  116744   1368   1312 S   1.3  0.0  93:26.54 auditd                                           
 3778 nginx     20   0  446488  14688   6564 S   1.3  0.1   2:18.80 php-fpm                                          
 3847 nginx     20   0  446316  14588   6548 S   1.3  0.1   2:19.29 php-fpm                                          
 7000 nginx     20   0  446132  14400   6544 S   1.3  0.1   1:22.77 php-fpm                                          
14862 nginx     20   0  446304  14600   6580 S   1.3  0.1   1:32.25 php-fpm                                          
30333 nginx     20   0  446292  14468   6528 S   1.3  0.1   1:40.78 php-fpm                                          
  740 root      20   0  784980  20112  19696 S   1.0  0.1  76:12.69 rsyslogd                                         
 3521 nginx     20   0  446188  14848   6748 S   1.0  0.1   2:20.00 php-fpm                                          
 3687 nginx     20   0  446036  14688   6764 S   1.0  0.1   2:20.45 php-fpm                                          
 3689 nginx     20   0  446408  14604   6552 S   1.0  0.1   2:19.75 php-fpm                                          
 3774 nginx     20   0  446288  14568   6552 S   1.0  0.1   2:19.68 php-fpm                                          
 3836 nginx     20   0  447416  15572   6564 S   1.0  0.1   2:21.06 php-fpm                                          
 4861 nginx     20   0  446260  14576   6540 S   1.0  0.1   2:18.94 php-fpm                                          
 4862 nginx     20   0  446508  15084   6764 S   1.0  0.1   2:20.71 php-fpm                                          
13538 nginx     20   0  447204  15452   6572 S   1.0  0.1   1:32.33 php-fpm                                          
15530 nginx     20   0  446292  14520   6528 S   1.0  0.1   1:32.55 php-fpm                                          
28468 nginx     20   0  446356  14672   6568 S   1.0  0.1   1:42.21 php-fpm                                          
29564 nginx     20   0  446292  14536   6548 S   1.0  0.1   1:41.11 php-fpm                                          
30851 nginx     20   0  445956  14568   6748 S   1.0  0.1   1:49.66 php-fpm

Editer 2-14-16

J'ai peut-être trouvé quelque chose de pertinent dans la sortie de "sudo journalctl" (voir ci-dessous). Il existe de nombreuses lignes se produisant chaque seconde pendant des heures à la fois concernant les connexions SSH à partir d'un de mes autres serveurs de production. Il s'agit de processus rsync transférant des fichiers du serveur distant vers le serveur en question. Cela s'avère expliquer l'utilisation du processeur de systemd, systemd-logind, NetworkManager et systemd-journal.

Cependant, cela ne pouvait pas expliquer la fuite de mémoire, qui est le plus gros problème. Depuis la rédaction originale de cet article il y a quelques jours, systemd est passé de 18,9% à 21,4% d'utilisation de la mémoire système.

Le journal ci-dessous a été modifié pour remplacer le vrai nom de domaine et l'adresse IP des serveurs.

Feb 14 10:02:13 hostname.domain.com systemd-logind[737]: New session 6467482 of user tropicg9.
Feb 14 10:02:13 hostname.domain.com systemd[1]: Started Session 6467482 of user tropicg9.
Feb 14 10:02:13 hostname.domain.com systemd[1]: Starting Session 6467482 of user tropicg9.
Feb 14 10:02:13 hostname.domain.com sshd[9665]: pam_unix(sshd:session): session opened for user tropicg9 by (uid=0)
Feb 14 10:02:13 hostname.domain.com sshd[9667]: Received disconnect from 1.2.3.4: 11: disconnected by user
Feb 14 10:02:13 hostname.domain.com sshd[9665]: pam_unix(sshd:session): session closed for user tropicg9
Feb 14 10:02:13 hostname.domain.com systemd-logind[737]: Removed session 6467482.
Feb 14 10:02:14 hostname.domain.com sshd[9728]: Accepted publickey for tropicg9 from 1.2.3.4 port 45289 ssh2: RSA 0b:
Feb 14 10:02:14 hostname.domain.com systemd-logind[737]: New session 6467483 of user tropicg9.
Feb 14 10:02:14 hostname.domain.com systemd[1]: Started Session 6467483 of user tropicg9.
Feb 14 10:02:14 hostname.domain.com systemd[1]: Starting Session 6467483 of user tropicg9.
Feb 14 10:02:14 hostname.domain.com sshd[9728]: pam_unix(sshd:session): session opened for user tropicg9 by (uid=0)
Feb 14 10:02:14 hostname.domain.com sshd[9735]: Received disconnect from 1.2.3.4: 11: disconnected by user
Feb 14 10:02:14 hostname.domain.com sshd[9728]: pam_unix(sshd:session): session closed for user tropicg9
Feb 14 10:02:14 hostname.domain.com systemd-logind[737]: Removed session 6467483.
Feb 14 10:02:15 hostname.domain.com sshd[9876]: Accepted publickey for tropicg9 from 1.2.3.4 port 45290 ssh2: RSA 0b:
Feb 14 10:02:15 hostname.domain.com systemd-logind[737]: New session 6467484 of user tropicg9.
Feb 14 10:02:15 hostname.domain.com systemd[1]: Started Session 6467484 of user tropicg9.
Feb 14 10:02:15 hostname.domain.com systemd[1]: Starting Session 6467484 of user tropicg9.
Feb 14 10:02:15 hostname.domain.com sshd[9876]: pam_unix(sshd:session): session opened for user tropicg9 by (uid=0)
Feb 14 10:02:15 hostname.domain.com sshd[9883]: Received disconnect from 1.2.3.4: 11: disconnected by user
Feb 14 10:02:15 hostname.domain.com sshd[9876]: pam_unix(sshd:session): session closed for user tropicg9
Feb 14 10:02:15 hostname.domain.com systemd-logind[737]: Removed session 6467484.
Feb 14 10:02:20 hostname.domain.com sshd[10333]: Accepted publickey for tropicg9 from 1.2.3.4 port 45291 ssh2: RSA 0b
Feb 14 10:02:20 hostname.domain.com systemd-logind[737]: New session 6467485 of user tropicg9.
Feb 14 10:02:20 hostname.domain.com systemd[1]: Started Session 6467485 of user tropicg9.
Feb 14 10:02:20 hostname.domain.com systemd[1]: Starting Session 6467485 of user tropicg9.
Feb 14 10:02:20 hostname.domain.com sshd[10333]: pam_unix(sshd:session): session opened for user tropicg9 by (uid=0)
Feb 14 10:02:20 hostname.domain.com sshd[10342]: Received disconnect from 1.2.3.4: 11: disconnected by user
Feb 14 10:02:20 hostname.domain.com sshd[10333]: pam_unix(sshd:session): session closed for user tropicg9
Feb 14 10:02:20 hostname.domain.com systemd-logind[737]: Removed session 6467485.
Feb 14 10:02:21 hostname.domain.com sshd[10450]: Accepted publickey for tropicg9 from 1.2.3.4 port 45292 ssh2: RSA 0b
Feb 14 10:02:21 hostname.domain.com systemd-logind[737]: New session 6467486 of user tropicg9.
Feb 14 10:02:21 hostname.domain.com systemd[1]: Started Session 6467486 of user tropicg9.
Feb 14 10:02:21 hostname.domain.com systemd[1]: Starting Session 6467486 of user tropicg9.
Feb 14 10:02:21 hostname.domain.com sshd[10450]: pam_unix(sshd:session): session opened for user tropicg9 by (uid=0)
Feb 14 10:02:21 hostname.domain.com sshd[10457]: Received disconnect from 1.2.3.4: 11: disconnected by user
Feb 14 10:02:21 hostname.domain.com sshd[10450]: pam_unix(sshd:session): session closed for user tropicg9
Feb 14 10:02:21 hostname.domain.com systemd-logind[737]: Removed session 6467486.
Feb 14 10:02:22 hostname.domain.com sshd[10473]: Accepted publickey for tropicg9 from 1.2.3.4 port 45293 ssh2: RSA 0b
Feb 14 10:02:22 hostname.domain.com systemd-logind[737]: New session 6467487 of user tropicg9.
Feb 14 10:02:22 hostname.domain.com systemd[1]: Started Session 6467487 of user tropicg9.
Feb 14 10:02:22 hostname.domain.com systemd[1]: Starting Session 6467487 of user tropicg9.
Feb 14 10:02:22 hostname.domain.com sshd[10473]: pam_unix(sshd:session): session opened for user tropicg9 by (uid=0)
Feb 14 10:02:22 hostname.domain.com sshd[10475]: Received disconnect from 1.2.3.4: 11: disconnected by user
Feb 14 10:02:22 hostname.domain.com sshd[10473]: pam_unix(sshd:session): session closed for user tropicg9
Feb 14 10:02:22 hostname.domain.com systemd-logind[737]: Removed session 6467487.
Feb 14 10:02:23 hostname.domain.com sshd[10484]: Accepted publickey for tropicg9 from 1.2.3.4 port 45294 ssh2: RSA 0b
Feb 14 10:02:23 hostname.domain.com systemd-logind[737]: New session 6467488 of user tropicg9.
Feb 14 10:02:23 hostname.domain.com systemd[1]: Started Session 6467488 of user tropicg9.
Feb 14 10:02:23 hostname.domain.com systemd[1]: Starting Session 6467488 of user tropicg9.
Feb 14 10:02:23 hostname.domain.com sshd[10484]: pam_unix(sshd:session): session opened for user tropicg9 by (uid=0)
Feb 14 10:02:23 hostname.domain.com sshd[10486]: Received disconnect from 1.2.3.4: 11: disconnected by user
Feb 14 10:02:23 hostname.domain.com sshd[10484]: pam_unix(sshd:session): session closed for user tropicg9
Feb 14 10:02:23 hostname.domain.com systemd-logind[737]: Removed session 6467488.
Feb 14 10:02:39 hostname.domain.com sshd[10654]: Accepted publickey for tropicg9 from 1.2.3.4 port 45295 ssh2: RSA 0b
Feb 14 10:02:39 hostname.domain.com systemd[1]: Started Session 6467489 of user tropicg9.
Feb 14 10:02:39 hostname.domain.com systemd-logind[737]: New session 6467489 of user tropicg9.
Feb 14 10:02:39 hostname.domain.com systemd[1]: Starting Session 6467489 of user tropicg9.
Feb 14 10:02:39 hostname.domain.com sshd[10654]: pam_unix(sshd:session): session opened for user tropicg9 by (uid=0)
Feb 14 10:02:39 hostname.domain.com sshd[10656]: Received disconnect from 1.2.3.4: 11: disconnected by user
Feb 14 10:02:39 hostname.domain.com sshd[10654]: pam_unix(sshd:session): session closed for user tropicg9
Feb 14 10:02:39 hostname.domain.com systemd-logind[737]: Removed session 6467489.session 6467489.

Mise à jour 2-16-16

Voici la sortie de systemd-cgtop montrant l'utilisation des ressources pour les groupes de contrôle actifs (faites défiler vers la droite). Cela montre toute l'utilisation intensive des ressources sous le chemin "racine". Cela ne semble pas le réduire, mais peut-être que ces informations pourraient être utiles.

Il n'y a que 86 fichiers de portée et répertoires associés sous / run / systemd / system /, jusqu'à 6 jours. Il y avait un problème où ces fichiers étaient orphelins pendant les connexions SSH, entraînant des milliers d'entrées et une charge CPU élevée, mais cela ne se produit pas ici.

Path                                                                          Tasks   %CPU   Memory  Input/s Output/s

/                                                                               296   30.5    11.3G   657.8K   893.0K
/system.slice/NetworkManager.service                                              1      -        -        -        -
/system.slice/auditd.service                                                      1      -        -        -        -
/system.slice/crond.service                                                       1      -        -        -        -
/system.slice/dbus.service                                                        1      -        -        -        -
/system.slice/irqbalance.service                                                  1      -        -        -        -
/system.slice/lvm2-lvmetad.service                                                1      -        -        -        -
/system.slice/mariadb.service                                                     2      -        -        -        -
/system.slice/nginx.service                                                      10      -        -        -        -
/system.slice/php-fpm.service                                                   101      -        -        -        -
/system.slice/polkit.service                                                      1      -        -        -        -
/system.slice/postfix.service                                                     3      -        -        -        -
/system.slice/rsyslog.service                                                     1      -        -        -        -
/system.slice/smartd.service                                                      1      -        -        -        -
/system.slice/sshd.service                                                        2      -        -        -        -
/system.slice/system-getty.slice/[email protected]                               1      -        -        -        -
/system.slice/systemd-journald.service                                            1      -        -        -        -
/system.slice/systemd-logind.service                                              1      -        -        -        -
/system.slice/systemd-udevd.service                                               1      -        -        -        -
/system.slice/tuned.service                                                       1      -        -        -        -
/system.slice/wpa_supplicant.service                                              1      -        -        -        -
/user.slice/user-1000.slice/session-7170741.scope                                 4      -        -        -        -

Effacement temporaire de la mémoire systemd

Il semble que l'exécution systemctl daemon-reexeclibère toute la mémoire allouée au processus PID 1. Cependant, la fuite continue. Une solution provisoire à ce problème consiste à définir un cron quotidien pour effacer la mémoire, mais cela ne corrige pas la fuite. J'ai soumis un bogue à Redhat car il s'agit de la version stable de systemd pour CentOS 7.x. Espérons que la fuite puisse être trouvée et colmatée.

linux kernel systemd meridionaljet
la source
Cela peut ne pas être lié, mais quelle est l'utilisation actuelle du disque (mémoire) de / run?
Aaron
Avez-vous gardé le système à jour?
Michael Hampton
@Aaron Utilise actuellement 11% de la partition 7 Go / run. Aucune des partitions système de niveau racine n'est presque pleine.
meridionaljet
3
Désolé, nous ne le savons pas, car ce n'était pas dans votre question.
Michael Hampton
4
Il y a eu récemment une fuite de mémoire liée à PAM dans systemd lors de l'utilisation de l'activation de socket. Serait-ce possible? github.com/systemd/systemd/issues/2187
Matt

Réponses:

3

Vérifiez la trace du processus systemd pour les appels mmap / mmunmap. Cela devrait révéler le problème:

yum install strace
strace -ff -p 1

C'est un moyen rapide et sale de diagnostiquer les fuites de mémoire. L'étendue du processus systemd devrait ressembler:

recvmsg (23, {msg_name (0) = NULL, msg_iov (1) = [{"WATCHDOG = 1", 4096}], msg_controllen = 32, {cmsg_len = 28, cmsg_level = SOL_SOCKET, cmsg_type = SCM_CREDENTIALS {pid = 620, uid = 0, gid = 0}}, msg_flags = MSG_CMSG_CLOEXEC}, MSG_DONTWAIT | MSG_CMSG_CLOEXEC) = 10
ouvert ("/ proc / 620 / cgroup", O_RDONLY | O_CLOEXEC) = 20
fstat (20, {st_mode = S_IFREG | 0444, st_size = 0, ...}) = 0
mmap (NULL, 4096, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0) = 0x7fcfd734e000
read (20, "10: cpuset: / \ n9: perf_event: / \ n8: hug" ..., 1024) = 164
fermer (20) = 0
munmap (0x7fcfd734e000, 4096) = 0

Il alloue de la mémoire, fait quelque chose, puis libère de la mémoire.
En vérifiant la trace des appels système que fait systemd, vous devriez découvrir où il ne peut pas terminer les appels et libérer la mémoire allouée.
Je suppose qu'il y a un problème avec les pseudo-systèmes de fichiers mal montés ou selinux, donc systemd ne peut pas terminer ses appels.

anx
la source
J'ai déjà accéléré le processus, mais la sortie pour les appels mmap est très vague (et nombreuse), et je ne sais personnellement pas comment l'utiliser pour localiser une fuite potentielle.
meridionaljet
1
J'ai modifié ma réponse avec une meilleure explication de l'utilisation de strace.
anx
2
l'arrière d'avoir un outil d'initialisation compliqué
asdmin