|
Autore: HostingPratico.com
Data: 2006-04-28
Vediamo come riconoscere il collo di bottiglia di un server analizzando un esempio reale di sovraccarico di un server MySql.
Abbiamo visto in un precedente articolo che cos'è il server load e come monitorarlo. Talvolta capita che il server abbia un carico eccessivamente elevato e che cominci a rallentare fino al blocco quasi totale (per la gioia dell'amminstratore di sistema).
Nella maggior parte dei casi ci sono 2 motivi per i quali il server è sovraccarico:
un processo sta consumando tutte le risorse
l'hardware che abbiamo a disposizione non riesce più a gestire le richieste
Nel primo caso killando il processo abbiamo ristabilito il server, nel secondo dovremo capire cosa rallenta il sistema ed intervenire sull'hardware.
Su sistemi linux ci vengono incontro alcuni fondamentali comandi come “top” e il pacchetto “sysstat”. Vediamo allora, partendo da un esempio pratico, come procedere..
La situazione
Ore 18:30, il server MySql rallenta. Dopo aver verificato con MRTG i carichi del server, ci accorgiamo che qualcosa non funziona. Ci logghiamo come root, lanciamo un “uptime” ed effettivamente il server è sovraccarico..
Il primo passo, TOP.
Innanzitutto dobbiamo capire cosa sta succedendo al sistema. Il comando “top” restituisce una radiografia dinamica del server, indicando i processi maggiormente attivi ed il consumo percentuale della cpu e della ram.
Un esempio di output è:
top - 18:37:01 up 18:42, 1 user, load average: 2.37, 2.28, 2.21
Tasks: 54 total, 1 running, 53 sleeping, 0 stopped, 0 zombie
Cpu(s): 25.6% us, 35.6% sy, 0.0% ni, 0.0% id, 38.8% wa, 0.0% hi, 0.0% si
Mem: 1036524k total, 1024408k used, 12116k free, 3620k buffers
Swap: 2714944k total, 736k used, 2714208k free, 785176k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
20290 root 16 0 88600 83m 4584 S 1.6 8.2 1:00.19 perl
Come è facile intuire questo server è troppo carico!
Da subito balza all'occhio l'utilizzo della cpu e un load sopra 1.50..
Analizzando gli stati della cpu vediamo che:
il 25.6% del tempo viene speso in user-mode (dai normali software in esecuzione)
il 35.6% del tempo viene speso in system-mode (dal kernel, probabilmente per allocare e deallocare memoria, visto l'ampio consumo di ram)
il 38.8% del tempo viene speso in waiting-mode (uno o più processi stanno aspettando un input o output, probabilmente dai dischi)
Andiamo a vedere l'utilizzo della ram e della swap. I valori sono al limite.
Probabilmente qualche processo sta lavorando troppo.
Spostiamoci sulla parte relativa ai processi, vediamo che non c'è nulla di strano, quindi non c'è un particolare processo che consuma eccessive risorse. Nel caso in cui ci fosse stato bastava un bel “kill -9 PID” dove al posto di PID va inserito il numero della colonna corrispondente (se per esempio perl stesse consumando troppo avremmo fatto “kill -9 20290”).
Con il solo utilizzo di “top” abbiamo già un'idea di cosa stia succedendo al sistema.
Proseguiamo con il debug.
Approfondiamo con SYSSTAT.
Cominciamo ad approfondire l'analisi del sistema verificando l'utilizzo delle singoli componenti hardware.
Lanciamo un “vmstat 5”:
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
2 2 736 4480 5488 787888 0 0 62 562 192 239 10 15 58 16
1 2 736 4508 5488 787888 0 0 0 2104 5283 67 2 98 0 0
0 3 736 10548 5488 788016 0 0 64 1996 5398 91 3 94 0 3
1 1 736 8968 5496 788016 0 0 0 2086 6070 72 0 97 0 2
Vediamo che la cpu è utilizzata al massimo, dal sistema e dall'input\output.
Allora lanciamo un “iostat -x 5”:
cpu-med: %user %nice %sys %iowait %idle
1,99 3,48 94,53 0,00 0,00
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s
hda 0,00 72,14 0,00 435,82 0,00 4147,26 0,00 2073,63
avgrq-sz avgqu-sz await svctm %util
9,52 140,79 319,54 2,27 99,10
Bene bene, utilizzo del disco al 99,10%. Vediamo che dice “man iostat”:
%util
Percentage of CPU time during which I/O requests were issued to the device (bandwidth utilization for the device). Device saturation occurs when this value is close to 100%.
Benissimo, stiamo saturando tutta la banda dell'hard-disk, ecco un possibile collo di bottiglia!
Vediamo che processi usano l'hard-disk.
Questa operazione è piuttosto semplice, basta lanciare il comando “lsof” che elenca i file aperti dai processi. Scorriamo lungo la lista e cerchiamo di trovare il possibile colpevole..
In questo caso ho trovato ben 150 voci attestate a “mysqld”!
La prova del nove.
MySql è sovraccarico, proviamo a stopparlo per vedere se tutto va a posto:
“/etc/init.d/mysql stop”, poi lanciamo un “top”.
Cpu(s): 0.0% us, 0.3% sy, 0.0% ni, 99.7% id, 0.0% wa, 0.0% hi, 0.0% si
Abbiamo trovato il problema, MySql che saturava l'hard-disk!
Conclusioni
Prima di spendere (e magari buttare via) soldi per aggiornare l'hardware è meglio verificare che il sistema sia configurato al meglio. In questo caso, prima di decidere di rivedere il reparto dischi, ho verificato che MySql non compiesse operazioni inutili di scrittura\lettura su disco.
Le mie prove si sono rivelate inutili, costringendomi ad intervenire sull'acquisto di un nuovo disco. In questo caso un Western Digital Raptor 10.000rpm SATA da 36gb\s, nel quale ho salvato i database di MySql ed ottenendo un incremento notevole di prestazioni, rimuovendo completamente il collo di bottiglia, il tutto con solo 100 euro circa di spesa e tanta voglia di fare debug di sistema!
|
