1 votes

L'exécution de gcore pourrait-elle augmenter la mémoire résidente (RSS) du processus cible sous Linux ?

gcore attache gdb à un processus, parcourt la plupart des zones de mémoire virtuelle d'un processus et les vide sur le disque. Est-ce que cela signifie que chaque morceau de mémoire virtuelle anonyme devra être paginé dans la mémoire de ce processus, ce qui augmentera son RSS, ou est-ce que la mémoire paginée dans l'espace de travail de l'utilisateur est la même ? gdb processus ? Je suppose qu'il va aussi paginer dans toute mémoire sauvegardée dans les fichiers (bien que je suppose que cela ne devrait pas augmenter le RSS, bien que cela puisse augmenter l'utilisation de la RAM par le cache des fichiers).

L'exemple d'un environnement Kubernetes montre des sauts de RSS de 304368 à 17135624 ( gcore exécuté à partir d'un pod de débogage d'un nœud de travail) :

# ps auxwww | head -1
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
# ps auxwww | grep 3899524 | grep -v grep
1000650+ 3899524  0.2  0.9 17229416 304368 ?     SLsl Jun13  54:01 /opt/java/openjdk/jre/bin/java [...]
# gcore 3899524
[...]
# ps auxwww | grep 3899524 | grep -v grep
1000650+ 3899524  0.2 53.3 17229416 17135624 ?   SLsl Jun13  54:01 /opt/java/openjdk/jre/bin/java [...]

Cela pourrait-il être lié spécifiquement aux conteneurs/cgroupes ?

2voto

John Mahowald Points 28597

L'écriture de la majeure partie de la mémoire d'un processus dans un fichier, comme un core dump, nécessite de le lire. La façon dont cela est mis en œuvre est spécifique au système d'exploitation.

Sur la plupart des systèmes POSIX, un processus (ou peut-être son fork) reçoit l'ordre de vider le noyau, que ce soit par un débogueur comme gcore ou la mort de la tâche dans certaines conditions. C'est plus efficace de cette façon, sinon la mémoire pourrait devoir être copiée d'un espace d'adressage à un autre.

Sous Linux, man core documente ce qui est déversé. /proc/[pid]/coredump_filter contient un masque de bits permettant de personnaliser cela. Notez que l'ensemble par défaut est constitué de quelques variantes de mappings anonymes ou privés. Les mappages de fichiers sont exclus par défaut, car ils peuvent être lus depuis le fichier après que la tâche soit partie.

Remarquez dans la sortie ps que la taille de l'ensemble des résidents (RSS) se rapproche de la taille de la mémoire virtuelle (VSZ) au fur et à mesure du vidage. Je suppose qu'un programme java avec 16 Go et plus de mémoire a la plupart de celle-ci dans le tas, peut-être statiquement dimensionné pour une utilisation en production. Un vidage complet de cette mémoire toucherait chaque page, même si la plupart d'entre elles sont encore des zéros non touchés.

Cela ne veut pas nécessairement dire qu'il faut faire une recherche à partir du swap. Bien que cela puisse arriver, les informations que vous avez fournies ne parlent pas de swap.

Le vidage du noyau d'un processus de cette taille représente beaucoup de frais généraux. A la fois en termes de CPU pour boucler toute la mémoire, et de stockage pour l'écrire. À éviter si possible, en faveur de méthodes de profilage et de débogage avec moins de frais généraux.

Les cgroups de Linux ne changent pas grand chose à ce sujet. Il permet surtout une comptabilité plus spécifique pour votre planification de la capacité. L'utilisation de la mémoire d'un conteneur spécifique ou d'une unité systemd correspond approximativement à la taille d'un core dump qu'il pourrait créer. Voir aussi systemd-cgtop -m

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X