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.