2012-03-09 14:13:35 +0000 2012-03-09 14:13:35 +0000
131
131

Linux : découvrir quel processus utilise toute la mémoire vive ?

Avant de demander, juste pour être clair : oui, je connais le cache disque, et non, ce n'est pas mon cas :) Désolé, pour ce préambule :)

j'utilise CentOS 5. Toutes les applications du système échangent beaucoup, et le système est très lent. Quand je fais free -m, voici ce que j'ai :

total used free shared buffers cached
Mem: 3952 3929 22 0 1 18
-/+ buffers/cache: 3909 42
Swap: 16383 46 16337

Donc, je n'ai en fait que 42 Mo à utiliser ! D'après ce que je comprends, -/+ buffers/cache ne compte pas le cache du disque, donc je n'ai en fait que 42 Mo, n'est-ce pas ? Je me suis dit que je pouvais me tromper, alors j'ai essayé de désactiver le cache disque et cela n'a eu aucun effet - l'image est restée la même.

Alors, j'ai décidé de trouver qui utilisait toute ma RAM, et j'ai utilisé top pour cela. Mais, apparemment, il rapporte qu'aucun processus n'utilise ma mémoire vive. Le seul processus dans mon top est MySQL, mais il utilise 0,1% de RAM et 400Mb de swap. Même image lorsque j'essaie d'exécuter d'autres services ou applications - tous vont dans le swap, top montre que le MEM n'est pas utilisé (0,1% maximum pour tout processus).

top - 15:09:00 up 2:09, 2 users, load average: 0.02, 0.16, 0.11
Tasks: 112 total, 1 running, 111 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 4046868k total, 4001368k used, 45500k free, 748k buffers
Swap: 16777208k total, 68840k used, 16708368k free, 16632k cached

  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ SWAP COMMAND
 3214 ntp 15 0 23412 5044 3916 S 0.0 0.1 0:00.00 17m ntpd
 2319 root 5 -10 12648 4460 3184 S 0.0 0.1 0:00.00 8188 iscsid
 2168 root RT 0 22120 3692 2848 S 0.0 0.1 0:00.00 17m multipathd
 5113 mysql 18 0 474m 2356 856 S 0.0 0.1 0:00.11 472m mysqld
 4106 root 34 19 251m 1944 1360 S 0.0 0.0 0:00.11 249m yum-updatesd
 4109 root 15 0 90152 1904 1772 S 0.0 0.0 0:00.18 86m sshd
 5175 root 15 0 90156 1896 1772 S 0.0 0.0 0:00.02 86m sshd

Restart n'aide pas, et, en passant, est très lent, ce à quoi je ne m'attendrais pas normalement sur cette machine (4 cœurs, 4Gb RAM, RAID1).

Donc, avec ça - je suis presque sûr que ce n'est pas un cache disque, qui utilise la mémoire vive, parce que normalement il aurait dû être réduit et laisser d'autres processus utiliser la mémoire vive, plutôt que d'aller à l'échange.

Donc, finalement, la question est - si quelqu'un a une idée de comment trouver quel processus utilise réellement la mémoire si fortement ?

Réponses (9)

115
115
115
2012-03-09 14:25:01 +0000

Sous Linux, dans le processus top, vous pouvez appuyer sur la touche < pour déplacer le tri de l'affichage de sortie vers la gauche. Par défaut, il est trié par le %CPU, donc si vous appuyez 4 fois sur la touche, vous le triez par le VIRT qui est la taille de la mémoire virtuelle vous donnant votre réponse.

Une autre façon de faire cela est :

ps -e -o pid,vsz,comm= | sort -n -k 2

devrait vous donner et la sortie triée par la taille virtuelle des processus.

Voici la version longue :

ps --everyone --format=pid,vsz,comm= | sort --numeric-sort --key=2
78
78
78
2016-02-09 21:12:26 +0000

Afficher la mémoire des processus en mégaoctets et le chemin du processus.

ps aux | awk '{print $6/1024 " MB\t\t" $11}' | sort -n
14
14
14
2012-10-15 15:05:01 +0000

Juste une note en marge sur un serveur présentant les mêmes symptômes mais montrant toujours un épuisement de la mémoire. Ce qu'on a fini par trouver, c'est un sysctl.conf provenant d'une boîte avec 32 Go de RAM et configuré pour une base de données avec des pages énormes configurées à 12000. Cette boîte n'a que 2 Go de mémoire vive, donc elle attribuait toute la mémoire vive libre aux énormes pages (seulement 960 d'entre elles). En réglant les pages énormes à 10, car aucune n'était utilisée de toute façon, on a libéré toute la mémoire.

Une vérification rapide de /proc/meminfo pour rechercher les paramètres de HugePages_ peut être un bon début pour dépanner au moins un monopolisateur de mémoire inattendu.

5
5
5
2018-03-31 03:38:27 +0000

Dans mon cas, le problème était que le serveur était un serveur virtuel VMware avec le module vmw_balloon activé :

$ lsmod | grep vmw_balloon
vmw_balloon 20480 0
vmw_vmci 65536 2 vmw_vsock_vmci_transport,vmw_balloon

en cours d'exécution :

$ vmware-toolbox-cmd stat balloon
5189 MB

Donc environ 5 Go de mémoire ont en fait été récupérés par l'hôte. Donc, bien que ma VM ait 8 Go de mémoire “officiellement”, dans la pratique, elle en a beaucoup moins :

$ free
              total used free shared buff/cache available
Mem: 8174716 5609592 53200 27480 2511924 2458432
Swap: 8386556 6740 8379816
2
2
2
2013-07-08 06:05:54 +0000

Vous pouvez également utiliser la commande ps pour obtenir plus d'informations sur le processus.

ps aux | less
2
2
2
2016-10-21 10:51:37 +0000

Je fais référence à this et Total memory used by Python process ? - Stack Overflow , c'est ma réponse. Je reçois un outil de comptage de processus (python) spécifique, maintenant.

# Megabyte.
$ ps aux | grep python | awk '{sum=sum+$6}; END {print sum/1024 " MB"}'
87.9492 MB

# Byte.
$ ps aux | grep python | awk '{sum=sum+$6}; END {print sum " KB"}'
90064 KB

Attachez ma liste de processus.

$ ps aux | grep python
root 943 0.0 0.1 53252 9524 ? Ss Aug19 52:01 /usr/bin/python /usr/local/bin/beaver -c /etc/beaver/beaver.conf -l /var/log/beaver.log -P /var/run/beaver.pid
root 950 0.6 0.4 299680 34220 ? Sl Aug19 568:52 /usr/bin/python /usr/local/bin/beaver -c /etc/beaver/beaver.conf -l /var/log/beaver.log -P /var/run/beaver.pid
root 3803 0.2 0.4 315692 36576 ? S 12:43 0:54 /usr/bin/python /usr/local/bin/beaver -c /etc/beaver/beaver.conf -l /var/log/beaver.log -P /var/run/beaver.pid
jonny 23325 0.0 0.1 47460 9076 pts/0 S+ 17:40 0:00 python
jonny 24651 0.0 0.0 13076 924 pts/4 S+ 18:06 0:00 grep python

Référence

1
1
1
2016-03-14 20:50:46 +0000

Faire un script appelé show-memory-usage.sh avec le contenu :

#!/bin/sh
ps -eo rss,pid,user,command | sort -rn | head -10 | awk '{ hr[1024**2]="GB"; hr[1024]="MB";
 for (x=1024**3; x>=1024; x/=1024) {
 if ($1>=x) { printf ("%-6.2f %s ", $1/x, hr[x]); break }
 } } { printf ("%-6s %-10s ", $2, $3) }
 { for ( x=4 ; x<=NF ; x++ ) { printf ("%s ",$x) } print ("\n") }
 '
0
0
0
2019-07-12 19:46:37 +0000

Mon serveur ubuntu DISTRIB RELEASE=18.04 sur Hyper-V a utilisé la plus grande partie de la mémoire, mais tous les processus se sont bien déroulés. (J'ai admis avoir supprimé les paquets snapd et unattended-upgr, mais 95% de la mémoire était encore utilisée).

La réponse est que Hyper-V a une mémoire dynamique, donc il a pris de la mémoire pour l'utilisation du système principal et ubuntu l'a marqué comme utilisé.

J'espère que ça aidera quelqu'un.

0
0
0
2019-03-31 17:51:48 +0000

Il prend également l'identifiant du processus, le trie par MB utilisé et décrit la commande (qui a créé le processus) :

ps aux | awk '{print $6/1024 " MB\t\t" $2 "\t" $11}' | sort -n