Il server Linux utilizza solo il 60% della memoria, quindi scambia

Ho un server Linux che esegue il nostro sistema di backup bacula. La macchina sta macinando come un matto perché sta andando pesantemente a scambiarsi. Il problema è che utilizza solo il 60% della sua memoria fisica!

Ecco l'output di free -m:

free -m
             total       used       free     shared    buffers     cached
Mem:          3949       2356       1593          0          0          1
-/+ buffers/cache:       2354       1595
Swap:         7629       1804       5824

e alcuni output di esempio da vmstat 1:

procs -----------memory---------- ---swap-- -----io---- -system-- -----cpu------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  2 1843536 1634512      0   4188   54   13  2524   666    2    1  1  1 89  9  0
 1 11 1845916 1640724      0    388 2700 4816 221880  4879 14409 170721  4  3 63 30  0
 0  9 1846096 1643952      0      0 4956  756 174832   804 12357 159306  3  4 63 30  0
 0 11 1846104 1643532      0      0 4916  540 174320   580 10609 139960  3  4 64 29  0
 0  4 1846084 1640272      0   2336 4080  524 140408   548 9331 118287  3  4 63 30  0
 0  8 1846104 1642096      0   1488 2940  432 102516   457 7023 82230  2  4 65 29  0
 0  5 1846104 1642268      0   1276 3704  452 126520   452 9494 119612  3  5 65 27  0
 3 12 1846104 1641528      0    328 6092  608 187776   636 8269 113059  4  3 64 29  0
 2  2 1846084 1640960      0    724 5948    0 111480     0 7751 116370  4  4 63 29  0
 0  4 1846100 1641484      0    404 4144 1476 125760  1500 10668 105358  2  3 71 25  0
 0 13 1846104 1641932      0      0 5872  828 153808   840 10518 128447  3  4 70 22  0
 0  8 1846096 1639172      0   3164 3556  556 74884   580 5082 65362  2  2 73 23  0
 1  4 1846080 1638676      0    396 4512   28 50928    44 2672 38277  2  2 80 16  0
 0  3 1846080 1628808      0   7132 2636    0 28004     8 1358 14090  0  1 78 20  0
 0  2 1844728 1618552      0  11140 7680    0 12740     8  763 2245  0  0 82 18  0
 0  2 1837764 1532056      0 101504 2952    0 95644    24  802 3817  0  1 87 12  0
 0 11 1842092 1633324      0   4416 1748 10900 143144 11024 6279 134442  3  3 70 24  0
 2  6 1846104 1642756      0      0 4768  468 78752   468 4672 60141  2  2 76 20  0
 1 12 1846104 1640792      0    236 4752  440 140712   464 7614 99593  3  5 58 34  0
 0  3 1846084 1630368      0   6316 5104    0 20336     0 1703 22424  1  1 72 26  0
 2 17 1846104 1638332      0   3168 4080 1720 211960  1744 11977 155886  3  4 65 28  0
 1 10 1846104 1640800      0    132 4488  556 126016   584 8016 106368  3  4 63 29  0
 0 14 1846104 1639740      0   2248 3436  428 114188   452 7030 92418  3  3 59 35  0
 1  6 1846096 1639504      0   1932 5500  436 141412   460 8261 112210  4  4 63 29  0
 0 10 1846104 1640164      0   3052 4028  448 147684   472 7366 109554  4  4 61 30  0
 0 10 1846100 1641040      0   2332 4952  632 147452   664 8767 118384  3  4 63 30  0
 4  8 1846084 1641092      0    664 4948  276 152264   292 6448 98813  5  5 62 28  0

Inoltre, l'output di top ordinati in base al tempo della CPU sembra supportare la teoria secondo cui lo swap è ciò che blocca il sistema:

top - 09:05:32 up 37 days, 23:24,  1 user,  load average: 9.75, 8.24, 7.12
Tasks: 173 total,   1 running, 172 sleeping,   0 stopped,   0 zombie
Cpu(s):  1.6%us,  1.4%sy,  0.0%ni, 76.1%id, 20.6%wa,  0.1%hi,  0.2%si,  0.0%st
Mem:   4044632k total,  2405628k used,  1639004k free,        0k buffers
Swap:  7812492k total,  1851852k used,  5960640k free,      436k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+    TIME COMMAND                                                                                                                             
 4174 root      17   0 63156  176   56 S    8  0.0   2138:52  35,38 bacula-fd                                                                                                                            
 4185 root      17   0 63352  284  104 S    6  0.0   1709:25  28,29 bacula-sd                                                                                                                            
  240 root      15   0     0    0    0 D    3  0.0 831:55.19 831:55 kswapd0                                                                                                                              
 2852 root      10  -5     0    0    0 S    1  0.0 126:35.59 126:35 xfsbufd                                                                                                                              
 2849 root      10  -5     0    0    0 S    0  0.0 119:50.94 119:50 xfsbufd                                                                                                                              
 1364 root      10  -5     0    0    0 S    0  0.0 117:05.39 117:05 xfsbufd                                                                                                                              
   21 root      10  -5     0    0    0 S    1  0.0  48:03.44  48:03 events/3                                                                                                                             
 6940 postgres  16   0 43596    8    8 S    0  0.0  46:50.35  46:50 postmaster                                                                                                                           
 1342 root      10  -5     0    0    0 S    0  0.0  23:14.34  23:14 xfsdatad/4                                                                                                                           
 5415 root      17   0 1770m  108   48 S    0  0.0  15:03.74  15:03 bacula-dir                                                                                                                           
   23 root      10  -5     0    0    0 S    0  0.0  13:09.71  13:09 events/5                                                                                                                             
 5604 root      17   0 1216m  500  200 S    0  0.0  12:38.20  12:38 java                                                                                                                                 
 5552 root      16   0 1194m  580  248 S    0  0.0  11:58.00  11:58 java

Ecco lo stesso ordinato per dimensione dell'immagine della memoria virtuale:

top - 09:08:32 up 37 days, 23:27,  1 user,  load average: 8.43, 8.26, 7.32
Tasks: 173 total,   1 running, 172 sleeping,   0 stopped,   0 zombie
Cpu(s):  3.6%us,  3.4%sy,  0.0%ni, 62.2%id, 30.2%wa,  0.2%hi,  0.3%si,  0.0%st
Mem:   4044632k total,  2404212k used,  1640420k free,        0k buffers
Swap:  7812492k total,  1852548k used,  5959944k free,      100k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+    TIME COMMAND                                                                                                                             
 5415 root      17   0 1770m   56   44 S    0  0.0  15:03.78  15:03 bacula-dir                                                                                                                           
 5604 root      17   0 1216m  492  200 S    0  0.0  12:38.30  12:38 java                                                                                                                                 
 5552 root      16   0 1194m  476  200 S    0  0.0  11:58.20  11:58 java                                                                                                                                 
 4598 root      16   0  117m   44   44 S    0  0.0   0:13.37   0:13 eventmond                                                                                                                            
 9614 gdm       16   0 93188    0    0 S    0  0.0   0:00.30   0:00 gdmgreeter                                                                                                                           
 5527 root      17   0 78716    0    0 S    0  0.0   0:00.30   0:00 gdm                                                                                                                                  
 4185 root      17   0 63352  284  104 S   20  0.0   1709:52  28,29 bacula-sd                                                                                                                            
 4174 root      17   0 63156  208   88 S   24  0.0   2139:25  35,39 bacula-fd                                                                                                                            
10849 postgres  18   0 54740  216  108 D    0  0.0   0:31.40   0:31 postmaster                                                                                                                           
 6661 postgres  17   0 49432    0    0 S    0  0.0   0:03.50   0:03 postmaster                                                                                                                           
 5507 root      15   0 47980    0    0 S    0  0.0   0:00.00   0:00 gdm                                                                                                                                  
 6940 postgres  16   0 43596   16   16 S    0  0.0  46:51.39  46:51 postmaster                                                                                                                           
 5304 postgres  16   0 40580  132   88 S    0  0.0   6:21.79   6:21 postmaster                                                                                                                           
 5301 postgres  17   0 40448   24   24 S    0  0.0   0:32.17   0:32 postmaster                                                                                                                           
11280 root      16   0 40288   28   28 S    0  0.0   0:00.11   0:00 sshd                                                                                                                                 
 5534 root      17   0 37580    0    0 S    0  0.0   0:56.18   0:56 X                                                                                                                                    
30870 root      30  15 31668   28   28 S    0  0.0   1:13.38   1:13 snmpd                                                                                                                                
 5305 postgres  17   0 30628   16   16 S    0  0.0   0:11.60   0:11 postmaster                                                                                                                           
27403 postfix   17   0 30248    0    0 S    0  0.0   0:02.76   0:02 qmgr                                                                                                                                 
10815 postfix   15   0 30208   16   16 S    0  0.0   0:00.02   0:00 pickup                                                                                                                               
 5306 postgres  16   0 29760   20   20 S    0  0.0   0:52.89   0:52 postmaster                                                                                                                           
 5302 postgres  17   0 29628   64   32 S    0  0.0   1:00.64   1:00 postmaster

Ho provato a sintonizzare il swappinessparametro del kernel su valori alti e bassi, ma nulla sembra cambiare il comportamento qui. Sono in perdita per capire cosa sta succedendo. Come posso scoprire cosa sta causando questo?

Aggiornamento: il sistema è completamente a 64 bit, quindi non dovrebbero esserci problemi di memoria a causa di problemi a 32 bit.

Aggiornamento2: Come ho già detto nella domanda originale, ho già provato a sintonizzare la swappiness su tutti i tipi di valori, incluso 0. Il risultato è sempre lo stesso, con circa 1,6 GB di memoria rimasti inutilizzati.

Aggiornamento 3: aggiunto l'output superiore alle informazioni sopra.

Le prestazioni di Bacula dipendono fortemente dal database. Probabilmente, è Postgresql che sta uccidendo il tuo server. La media del carico elevato e la percentuale abbastanza grande di tempo della CPU trascorso nello stato di attesa mostrano chiaramente che sta aspettando l'I / O del disco ... E questo è PostgreSQL. Per ogni file nel backup, imposta almeno un'istruzione UPDATE. Non preoccuparti per lo scambio.

Ottimizza l'installazione di PostgreSQL. Possibilmente dare al singolo database (o persino alle tabelle) i propri dischi / set di raid per diffondere l'I / O. È possibile forzare PostgreSQL a utilizzare le scritture aynschronous se non lo è già ... Anche se si tratta dell'integrità del database per le prestazioni di scrittura. Potenzia la memoria condivisa disponibile per PostgreSQL. Ciò consentirà di alleviare almeno molte delle letture nel database. Se non l'hai mai fatto, esegui VACCUM ANALYZE anche sul database Bacula per dare all'ottimizzatore di query qualcosa su cui lavorare.

Di gran lunga, il punto più debole di Bacula sono le dipendenze del database (e la morte cerebrale di alcune di esse ...) Eseguire un'eliminazione di un recente backup di grandi dimensioni e notare quanto tempo (ore spesso) ci vuole per eseguire una dozzina di milioni di query. .. A Bacula piacciono relativamente pochi file di grandi dimensioni, altrimenti è un cane.

Sei associato a I / O. Il tuo sistema è una piccola zattera di salvataggio, avvolta in un mare in tempesta di onde di paging buffer / cache / VM alte 100 piedi.

Wow. Solo ... wow. Stai spostando di circa 100 MB / sec il tuo I / O, stai superando il 50% del tempo CPU nell'attesa I / O e hai 4 GB di RAM. La contropressione sulla VM di questo server deve essere enorme. In circostanze "normali", quando il sistema inizia a bufferizzare / memorizzare nella cache, qualsiasi RAM libera che hai sarà consumata viva in meno di 40 secondi .

Sarebbe possibile pubblicare le impostazioni da /proc/sys/vm? Ciò fornirebbe alcune informazioni su ciò che il kernel ritiene "normale".

Questi postmasterprocessi indicano anche che stai eseguendo PostgreSQL in background. È normale per la tua configurazione? PostgreSQL in una configurazione predefinita utilizzerà pochissima RAM, ma una volta sintonizzato per aumentare la velocità, può masticare rapidamente il 25% -40% della RAM disponibile. Quindi posso solo indovinare, dato il numero di essi nell'output, stai eseguendo un qualche tipo di database di produzione mentre esegui i backup. Questo non è di buon auspicio. Puoi darci qualche informazione in più sul perché è in esecuzione? Qual è la dimensione del parametro di memoria condivisa per tuttipostmasterprocessi? Sarebbe possibile chiudere il servizio o riconfigurare temporaneamente il database per utilizzare meno connessioni / buffer mentre i backup sono in esecuzione? Ciò contribuirà a scaricare parte della pressione dall'I / O già sottoposto a tensione e dalla RAM libera. Tenere presente che ogni postmasterprocesso consuma RAM al di là di ciò che il database utilizza per la memorizzazione nella cache interna. Pertanto, quando si apportano modifiche alle impostazioni della memoria, fare attenzione a quali sono "condivise" e quali sono "per processo" .

Se stai usando PostgreSQL come parte del tuo processo di backup, prova a risintonizzarlo per accettare solo il numero minimo di connessioni e assicurati di ridurre i parametri per processo a qualcosa di ragionevole (solo pochi mega ciascuno). L'aspetto negativo di questo è che PostgreSQL si riverserà su disco se non può lavorare con il set di dati nella RAM, come vuole, in modo che sarà effettivamente aumentare il disco I / O , in modo da mettere a punto con cura.

X11 in sé e per sé non occupa molta memoria, ma una sessione desktop completa può consumare diversi mega. Esci da tutte le sessioni attive che hai ed esegui la connessione dalla console o tramite SSH.

Tuttavia, non penso che sia interamente un problema di memoria. Se si è migliori del 50% di I / O in attesa di lunghi periodi di tempo (e si pubblicano cifre che toccano gli anni '70), il collo di bottiglia risultante finirà per schiacciare il resto del sistema. Proprio come Darth Vader si schiaccia il collo.

Per quanti thread flush sei configurato? Uso

cat /proc/sys/vm/nr_pdflush_threads

per scoprire e

echo "vm.nr_pdflush_threads = 1" >> /etc/sysctl.conf

per impostarlo su un singolo thread. Si noti che l'ultimo comando lo fa caricare in modo permanente al riavvio. Vedere 1 o 2 non è insolito. Se si dispone di più core o di una grande capacità del mandrino / bus per l'I / O, è necessario aumentarli leggermente. Più thread flush = più attività I / O, ma anche più tempo della CPU impiegato nell'attesa I / O.

È il valore predefinito o l'hai superato? Se lo hai superato, hai considerato di ridurre il numero per ridurre la pressione sulle operazioni di I / O? Oppure hai un numero enorme di mandrini e canali con cui lavorare, nel qual caso hai preso in considerazione l'idea di aumentare il numero di thread flush?

PS vuoi impostare lo swappiness sui valori più bassi, non sui valori più alti, per impedire lo swap-out. Valore più alto = 100 = scambia come un matto quando sembra giusto, valore più basso = 0 = cerca di non scambiare affatto.

Se guardi i blocchi letti al secondo (bi) sotto IO, sminuisce l'attività di scambio di più ordini di grandezza. Non penso che l'utilizzo dello swap sia ciò che sta causando il crash del disco, penso che tu abbia qualcosa in esecuzione sulla scatola che sta semplicemente causando molta attività sul disco (letture).

Esaminerei le applicazioni in esecuzione e vedrei se riesci a trovare il colpevole.

Verifica se questo link risponde ad alcune delle tue domande. Vedo regolarmente il paging di Linux (non lo scambio) di memoria molto prima dell'utilizzo del 60%. Questo è un pezzo atteso della sua messa a punto della memoria:

http://www.sheepguardingllama.com/?p=2252

Ma la tua mancanza di buffer / cache mi preoccupa. Sembra molto insolito. Quindi sto pensando che qualcosa di più non va.

Puoi provare a disabilitare completamente lo swap?

swapoff /dev/hdb2

o alcuni di questi, almeno ciò confermerà che è il tuo problema lo scambio e non qualcos'altro.

Per impostazione predefinita, lo swappiness è impostato su 60.

cat / proc / sys / vm / swappiness 60

Swappiness è un kernel usato per modificare quanto il kernel preferisce scambiare su RAM; swapiness elevato significa che il kernel cambierà molto e swapiness basso significa che il kernel tenterà di non usare lo spazio di swap.

Possiamo modificare questa modifica del valore di vm.swappiness in /etc/sysctl.conf .

Puoi impostare manualmente lo swappinness del kernel, che puoi vedere /proc/sys/vm/swappinesso emettere il comando sysctl vm.swappiness. Lo swappiness è un'impostazione del kernel che determina la quantità di swap utilizzata.

Impostando sudo sysctl vm.swappiness=0si sta disattivando efficacemente la partizione di swap. Per rendere questa modifica permanente è possibile aggiungere / modificare vm.swappiness=0in /etc/sysctl.conf. Dovresti vedere quale è un buon valore per te. Personalmente l'ho configurato su vm.swappiness=10, essendo 60 il valore predefinito.

Un'altra cosa che potresti voler guardare è la coda di esecuzione del tuo kernel e i processi non interrompibili (le colonne 'r' e 'b' in vmstat) sono un indicatore che il sistema è saturo a volte. In una nota a margine, non confondere la saturazione con l'utilizzo ... il vero problema potrebbe essere uno stack di processo affamato contro il kernel saturo :-(

È inoltre possibile eseguire 'pmap -x [PID]' per ottenere ulteriori dettagli sulla memoria da alcuni dei processi più dispendiosi. Ti auguro buona fortuna!

opaco

Forse hai processi di breve durata che utilizzano molta memoria, quindi si chiudono prima che tu abbia la possibilità di notarli.

Ciò sarebbe coerente con quello che stai vedendo comunque.

Hai studiato problemi con la cache degli inode? slabtopdovrebbe almeno darti un punto di partenza se ti imbatti in qualcosa di simile.

Mentre il sistema è a 64 bit, il sistema potrebbe non essere in grado di indirizzare effettivamente tutta la memoria disponibile. Questa è una limitazione del chipset. Ad esempio, il Mac mini di generazione precedente "supporta" 4 GB di RAM ma solo 3,3 GB era effettivamente indirizzabile.