Comment trouver ce qui utilise le swap linux ou ce qui est dans le swap?

12

J'ai un serveur Linux virtuel (Fedora 17) avec 28 Go de RAM et 2 Go de swap. Le serveur exécute une base de données MySQL configurée pour utiliser la majeure partie de la RAM.

Après un certain temps, le serveur commence à utiliser swap pour échanger les pages non publiées. C'est très bien car mon swappiness est à 60 par défaut et c'est le comportement attendu.

Ce qui est étrange, c'est que le nombre dans top / meminfo ne correspond pas aux informations des processus. C'est-à-dire que le serveur rapporte ces chiffres:

/proc/meminfo:
SwapCached:        24588 kB
SwapTotal:       2097148 kB
SwapFree:         865912 kB

top:
Mem:  28189800k total, 27583776k used,   606024k free,   163452k buffers
Swap:  2097148k total,  1231512k used,   865636k free,  6554356k cached

Si j'utilise le script de /server//a/423603/98204, il rapporte des nombres raisonnables (quelques Mo échangés par bash'es, systemd, etc.) et une grosse allocation de MySQL (j'ai omis beaucoup de lignes de sortie ):

892        [2442] qmgr -l -t fifo -u
896        [2412] /usr/libexec/postfix/master
904        [28382] mysql -u root
976        [27559] -bash
984        [27637] -bash
992        [27931] SCREEN
1000       [27932] /bin/bash
1192       [27558] sshd: admin@pts/0
1196       [27556] sshd: admin [priv]
1244       [1] /usr/lib/systemd/systemd
9444       [26626] /usr/bin/perl /bin/innotop
413852     [31039] /usr/libexec/mysqld --basedir=/usr --datadir=/data/mysql --plugin-dir=/usr/lib64/mysql/plugin --log-error=/data/mysql/err --open-files-limit=8192 --pid-file=/data/mysql/pid --socket=/data/mysql/mysql.sock --port=3306
449264   Total Swap Used

Donc, si j'obtiens la sortie de script correctement, l'utilisation totale du swap devrait être de 449264K = ca. 440 Mo avec mysql en utilisant ca. 90% du swap.

La question est de savoir pourquoi cela diffère tellement des chiffres supérieurs et meminfo? Existe-t-il un moyen de "vider" les informations de swap pour voir ce qui s'y trouve réellement au lieu de résumer les utilisations de swap de tous les processus?

Lors de l'analyse du problème, j'ai proposé différentes idées, mais elles semblent toutes fausses:

  1. La sortie du script n'est pas en Ko. Même si ce serait en unités de 512 ou 4 Ko, cela ne correspondra pas. En fait, le rapport (1200: 440) est d'environ 3: 1, ce qui est un nombre "étrange".
  2. Il y a quelques pages dans swap qui sont en quelque sorte partagées entre les processus comme mentionné dans /server//a/477664/98204 . Si cela est vrai, comment puis-je trouver le nombre réel de mémoire utilisé comme ça? Je veux dire qu'il faudrait faire une différence d'environ 800 Mo. Et cela ne sonne pas juste dans ce scénario.
  3. Il y a quelques "anciennes" pages dans swap utilisées par des processus déjà terminés. Cela ne me dérangerait pas que si je pouvais savoir combien coûte ce swap "libre".
  4. Il y a des pages de swap qui ont été remises en mémoire et qui sont en swap juste au cas où elles n'ont pas changé dans la RAM et doivent être à nouveau swappées comme mentionné dans /server//a/100636/98204 . Mais la valeur SwapCached n'est que de 24 Mo.

Ce qui est étrange, c'est que l'utilisation du swap augmente lentement alors que la somme de sortie du script est à peu près la même. Au cours des 3 derniers jours, le swap utilisé est passé de 1100 Mo à 1230 Mo actuel tandis que la somme est passée de 430 Mo à 449 Mo actuel (ca.).

Le serveur dispose de suffisamment de RAM (capable) pour que je puisse simplement désactiver le swap et le réactiver. Ou je pourrais probablement définir le swappiness à 0 afin que le swap ne soit utilisé que s'il n'y a pas d'autre moyen. Mais je voudrais résoudre le problème ou au moins découvrir quelle en est la cause.

Radek Hladík
la source
Comme vous le dites, vous devez simplement définir vm.swappiness = 0 (ou 1) et swapoff && swapon
HTTP500
Mais cela ne résoudrait pas le problème. Je suppose que le swap recommencerait à augmenter si je remettais les swappines à 60 ou ne serait pas utilisé du tout si je le maintiens à 0 ou 1 (à moins que le serveur ne manque de mémoire)
Radek Hladík
S'il s'agit d'un serveur DB, il ne doit utiliser swap qu'en cas d'urgence, vous devez donc toujours le définir sur 0 (ou 1).
HTTP500
C'est vrai et c'est probablement ce que je vais faire si je ne trouve pas la cause de ce problème ... D'un autre côté, il y a beaucoup de petites bases de données sur le serveur qui sont utilisées de manière très sporadique et j'ai aimé l'idée qu'elles soient échangés par le système lorsqu'ils ne sont pas utilisés ... Cependant, je suppose que MySQL sera capable de le gérer seul ...
Radek Hladík
Mysql gère très bien ses propres caches, mais cela est basé sur des hypothèses sur ce qui est en fait en mémoire et ce qui ne l'est pas. Si vous essayez de le deviner en utilisant la mémoire d'échange, vous comprenez simplement la capacité de mysql à décider ce qui doit être mis en cache et ce qui ne le doit pas. Désactivez le swap. SI vous appuyez sur swap, c'est un échec de réglage. Ajustez la taille de votre cache pour que l'échange ne se produise jamais, mais à court de cela, vous souhaitez utiliser toute la mémoire physique disponible.
mc0e

Réponses:

9

Fedora 18 et plus ont smemdans les dépôts. Vous pouvez télécharger le script python et l'installer à partir des sources .

Voici un exemple de sortie (quelque peu coupée et anonymisée) de ma machine:

# smem -s swap -t -k -n
  PID User     Command                         Swap      USS      PSS      RSS 
20917 1001     bash                               0     1.1M     1.1M     1.9M 
28329 0        python /bin/smem -s swap -t        0     6.3M     6.5M     7.4M 
 2719 1001     gnome-pty-helper               16.0K    72.0K    73.0K   516.0K 
  619 0        @sbin/mdadm --monitor --sca    28.0K    72.0K    73.0K   248.0K 

[big snip]

32079 42       gnome-shell --mode=gdm         41.9M     1.9M     2.0M     5.0M 
32403 1001     /opt/google/chrome/chrome -    43.1M   118.5M   119.4M   132.3M 
 4844 1002     /opt/google/chrome/chrome      48.1M    38.1M    41.9M    51.9M 
 5411 1002     /opt/google/chrome/chrome -    54.6M    33.4M    33.5M    36.8M 
 5624 1002     /opt/google/chrome/chrome -    72.4M    54.9M    55.5M    65.7M 
24328 1002     /opt/Adobe/Reader9/Reader/i    77.5M     1.9M     2.0M     5.2M 
 4921 1002     /opt/google/chrome/chrome -   147.2M   258.4M   259.4M   272.0M 
-------------------------------------------------------------------------------
  214 14                                       1.1G     1.1G     1.2G     1.7G 

La source fournit également smemcapqui stockera toutes les données pertinentes afin que smem puisse y être exécuté plus tard.

   To  capture  memory statistics on resource-constrained systems, the the
   smem source includes a utility named  smemcap.   smemcap  captures  all
   /proc entries required by smem and outputs them as an uncompressed .tar
   file to STDOUT.  smem can analyze the output using the --source option.
   smemcap is small and does not require Python.
rickhg12hs
la source
1
Smem du repo F17 n'a pas fonctionné (a montré une liste vide) mais celui de la source a fonctionné et affiche presque les mêmes chiffres que les autres :-) mysql 358,1M sur un total de 392,6M, tandis que le top affiche 1191224k utilisés
Radek Hladík
4

Vous devriez vérifier ce script sur une autre machine, car mon système affiche une utilisation de swap correcte:

# Your_script.sh
111280   Total Swap Used
# free
Swap:     33551716     120368   33431348

Très proche 111280 ~ = 120368.

Regardez également ce script:

pour proc dans / proc / *; faire cat $ proc / smaps 2> / dev / null | awk '/ Swap / {swap + = $ 2} END {print swap "\ t' readlink $proc/exe'"}'; fait | sort -n | awk '{total + = $ 1} / [0-9] /; END {print total "\ tTotal"}'

De ce fil:

/unix/71714/linux-total-swap-used-swap-used-by-processes

brin
la source
Le script mentionné renvoie les mêmes résultats ... 364920 / usr / libexec / mysqld 400372 Total
Radek Hladík
Lorsque j'ai essayé le script sur un autre serveur avec une utilisation de swap très faible (50 Mo), il a rapporté 72 Mo au total :-) Je devrai le simuler sur un serveur non productif plus tard ...
Radek Hladík