Come trovare cosa sta usando Linux Swap o cosa c'è nello Swap?


12

Ho un server Linux virtuale (Fedora 17) con 28 GB di RAM e 2 GB di swap. Il server esegue un DB MySQL impostato per utilizzare la maggior parte della RAM.

Dopo un po 'di tempo in esecuzione, il server inizia a utilizzare lo scambio per scambiare pagine senza coda. Va bene dato che la mia swappiness è di default 60 ed è il comportamento previsto.

La cosa strana è che il numero in alto / meminfo non corrisponde alle informazioni dai processi. Cioè il server sta segnalando questi numeri:

/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

Se uso lo script da /server//a/423603/98204 riporta numeri ragionevoli (pochi MB scambiati da bash'es, systemd, ecc.) E una grande allocazione da MySQL (ho omesso molte linee di output ):

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

Quindi, se ottengo l'output dello script corretto, l'utilizzo totale dello swap dovrebbe essere 449264K = ca. 440 MB con mysql usando ca. 90% dello swap.

La domanda è: perché questo differisce così tanto dai numeri top e meminfo? Esiste un modo per "scaricare" le informazioni di scambio per vedere cosa contiene effettivamente invece di sommare gli utilizzi di scambio da tutti i processi?

Quando ho analizzato il problema, mi sono venute in mente idee diverse, ma tutte sembrano sbagliate:

  1. L'output dello script non è in KB. Anche se sarebbe in unità da 512 o 4KB non corrisponderebbe. In realtà il rapporto (1200: 440) è di circa 3: 1 che è un numero "strano".
  2. Ci sono alcune pagine in scambio che sono in qualche modo condivise tra i processi come menzionato in /server//a/477664/98204 . Se questo è vero, come posso trovare il numero effettivo di memoria utilizzata in questo modo? Voglio dire che dovrebbe fare la differenza di cca 800 MB. E questo non suona proprio in questo scenario.
  3. Esistono alcune "vecchie" pagine in swap utilizzate da processi già terminati. Non mi dispiacerebbe che se fossi in grado di scoprire quanto è questo scambio "libero".
  4. Ci sono pagine di swap che sono state ricambiate in memoria e sono in swap nel caso in cui non siano cambiate nella RAM e debbano essere scambiate di nuovo come menzionato in /server//a/100636/98204 . Ma il valore di SwapCached è solo 24 MB.

La cosa strana è che l'utilizzo dello swap sta lentamente aumentando mentre l'output della somma dallo script è approssimativamente lo stesso. Negli ultimi 3 giorni lo swap utilizzato è aumentato da 1100 MB agli attuali 1230 MB, mentre la somma è aumentata da 430 MB agli attuali 449 MB (ca.).

Il server ha abbastanza RAM libera (in grado) in modo da poter semplicemente disattivare lo scambio e riaccenderlo. Oppure potrei probabilmente impostare lo swappiness su 0 in modo che lo swap venga utilizzato solo se non è diversamente. Ma vorrei risolvere il problema o almeno scoprire qual è la causa di questo.


Come dici tu, dovresti semplicemente impostare vm.swappiness = 0 (o 1) e swapoff && swapon
— HTTP500

Ma ciò non risolverebbe il problema. Suppongo che lo swap ricomincerebbe ad aumentare se ripristinassi gli swappines a 60 o non lo usassi affatto se lo tengo a 0 o 1 (a meno che il server non esaurisca la memoria)
— Radek Hladík

Se si tratta di un server DB, dovrebbe utilizzare lo scambio solo in caso di emergenza, quindi è necessario impostarlo sempre su 0 (o 1).
— HTTP500,

Questo è vero ed è probabilmente quello che farò se non trovo la causa di questo problema ... D'altra parte ci sono molti piccoli DB sul server che vengono usati molto sporadicamente e mi piaceva l'idea che fossero sostituito dal sistema quando non sono in uso ... Tuttavia suppongo che MySQL sarà in grado di gestirlo da solo ...
— Radek Hladík

Mysql fa un ottimo lavoro nel gestire le proprie cache, ma si basa su ipotesi su ciò che è effettivamente nella memoria e cosa no. Se provi a indovinarlo due volte usando la memoria di swap, stai solo compromettendo la capacità di mysql di decidere cosa deve essere memorizzato nella cache e cosa no. Disattiva scambio. Se si esegue lo scambio, si tratta di un errore di ottimizzazione. Modifica le dimensioni della cache in modo che lo scambio non avvenga mai, ma a parte questo, vuoi utilizzare tutta la memoria fisica disponibile.
— MC0e

Risposte:


9

Fedora dai 18 anni in su smemnei repository. È possibile scaricare lo script Python e installarlo dal sorgente .

Ecco un output di esempio (un po 'frammentato e anonimo) dalla mia macchina:

# 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 fonte fornisce anche smemcapche memorizzerà tutti i dati rilevanti in modo che smem possa essere eseguito su di esso in un secondo momento.

   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.

1
Smem dal repository F17 non ha funzionato (ha mostrato un elenco vuoto) ma quello della fonte ha funzionato e mostra quasi gli stessi numeri degli altri :-) mysql 358.1M su 392.6M totali, mentre i top show 1191224k utilizzati
— Radek Hladík

4

Dovresti controllare questo script su un altro computer, perché il mio sistema mostra l'uso corretto dello scambio:

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

Molto vicino 111280 ~ = 120368.

Inoltre, guarda questo script:

per proc in / proc / *; fai cat $ proc / smaps 2> / dev / null | awk '/ Swap / {swap + = $ 2} END {print swap "\ t' readlink $proc/exe'"}'; fatto | ordina -n | awk '{total + = $ 1} / [0-9] /; END {stampa totale "\ tTotal"}'

Da questa discussione:

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


Lo script citato sta restituendo gli stessi risultati ... 364920 / usr / libexec / mysqld 400372 Totale
— Radek Hladík

Quando ho provato lo script su un altro server con un utilizzo di swap molto basso (50 MB), ha riportato un totale di 72 MB circa :-) In seguito dovrò simularlo su un server di non produzione ...
— Radek Hladík,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.