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 obtenu:
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! Autant que je sache, -/+ buffers/cache
ne compte pas le cache disque, alors je n'ai en effet que 42 Mo, n'est-ce pas? J'ai pensé que je pouvais me tromper, alors j'ai essayé de désactiver la mise en cache du disque et cela n'a eu aucun effet - l'image est restée la même.
Alors, j'ai décidé de trouver qui utilise toute ma mémoire RAM, et j'ai utilisé top
pour cela. Mais, apparemment, il indique qu'aucun processus n'utilise ma RAM. Le seul processus dans mon top est MySQL, mais il utilise 0,1% de RAM et 400 Mo de swap. Même image lorsque j'essaie d'exécuter d'autres services ou applications - tous vont en permutation. top
indique que 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
Le redémarrage n'aide pas, et, par leur chemin est très lent, ce à quoi je ne m'attendrais pas normalement sur cette machine (4 cœurs, 4 Go de RAM, RAID1).
Donc, avec cela - je suis à peu près sûr que ce n'est pas un cache de disque, qui utilise la RAM, car normalement, il aurait dû être réduit et laisser les autres processus utiliser la RAM plutôt que de passer à l'échange.
Donc, pour finir, la question est la suivante: si quelqu'un a des idées, comment savoir quel processus utilise réellement la mémoire de manière aussi importante?
Sous Linux, dans le processus top
, vous pouvez appuyer sur la touche <
pour décaler le tri de l'affichage de sortie à gauche. Par défaut, il est trié selon le %CPU
. Par conséquent, si vous appuyez 4 fois sur la touche, vous pourrez le trier par VIRT
, ce qui correspond à la taille de la mémoire virtuelle, ce qui vous donnera votre réponse.
Une autre façon de faire est:
ps -e -o pid,vsz,comm= | sort -n -k 2
devrait vous donner et la sortie triée par processus taille virtuelle.
Voici la version longue:
ps --everyone --format=pid,vsz,comm= | sort --numeric-sort --key=2
Affiche 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
Juste une note sur un serveur présentant les mêmes symptômes, mais toujours épuisée par la mémoire. Ce qui a fini par trouver était un sysctl.conf dans une boîte avec 32 Go de RAM et la configuration d’un DB avec d’énormes pages configurées à 12000. Cette boîte ne contient que 2 Go de RAM il assignait tous les RAM libres aux grandes pages (seulement 960 d'entre elles). La définition d’énormes pages à 10, aucune d’elles n’ayant été utilisée, libère toute la mémoire.
Une vérification rapide de/proc/meminfo pour rechercher les paramètres HugePages_ peut être un bon début pour dépanner au moins un bourreau de mémoire inattendu.
Vous pouvez également utiliser la commande ps pour obtenir plus d'informations sur le processus.
ps aux | less
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
Fonctionnement:
$ vmware-toolbox-cmd stat balloon
5189 MB
Ainsi, environ 5 Go de mémoire ont en fait été récupérés par l'hôte. Donc, malgré le fait d'avoir 8 Go sur mon VM "officiellement", en pratique, c'était beaucoup moins:
$ free
total used free shared buff/cache available
Mem: 8174716 5609592 53200 27480 2511924 2458432
Swap: 8386556 6740 8379816
Créez 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") }
'
Je référence this et Mémoire totale utilisée par le processus Python? - Stack Overflow , voilà ma réponse. Je reçois maintenant un outil de comptage de processus spécifique (python).
# 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
Joignez 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