wa (Waiting for I / O) dal comando in alto è grande

Ho un forum con molti visitatori, alcuni giorni il carico aumenta per raggiungere 40 senza aumentare il numero di visitatori. Come si può vedere dall'output seguente, il tempo di attesa è elevato (57%). come trovo il motivo?
Il software server è Apache, MySQL e PHP.

root@server:~# top
top - 13:22:08 up 283 days, 22:06,  1 user,  load average: 13.84, 24.75, 22.79
Tasks: 333 total,   1 running, 331 sleeping,   0 stopped,   1 zombie
Cpu(s): 20.6%us,  7.9%sy,  0.0%ni, 13.4%id, 57.1%wa,  0.1%hi,  0.9%si,  0.0%st
Mem:   4053180k total,  3868680k used,   184500k free,   136380k buffers
Swap:  9936160k total,    12144k used,  9924016k free,  2166552k cached

 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
23930 mysql     20   0  549m 122m 6580 S   90  3.1   4449:04 mysqld
17422 www-data  20   0  223m  20m  10m S    2  0.5   0:00.21 apache2
17555 www-data  20   0  222m  19m 9968 S    2  0.5   0:00.13 apache2
17264 www-data  20   0  225m  19m 8972 S    1  0.5   0:00.17 apache2
17251 www-data  20   0  220m  12m 4912 S    1  0.3   0:00.12 apache2

.

root@server:~# top
top - 13:39:59 up 283 days, 22:24,  1 user,  load average: 6.66, 10.39, 13.95
Tasks: 318 total,   1 running, 317 sleeping,   0 stopped,   0 zombie
Cpu(s): 13.6%us,  4.2%sy,  0.0%ni, 40.5%id, 40.6%wa,  0.2%hi,  0.8%si,  0.0%st
Mem:   4053180k total,  4010992k used,    42188k free,   119544k buffers
Swap:  9936160k total,    12160k used,  9924000k free,  2290716k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
23930 mysql     20   0  549m 122m 6580 S   44  3.1   4457:30 mysqld
19946 www-data  20   0  223m  21m  10m S    5  0.6   0:00.77 apache2
17316 www-data  20   0  226m  23m  11m S    1  0.6   0:01.76 apache2
17333 www-data  20   0  222m  21m  11m S    1  0.5   0:01.55 apache2
18212 www-data  20   0  225m  22m  11m S    1  0.6   0:01.58 apache2
19528 www-data  20   0  220m  13m 5480 S    1  0.3   0:00.63 apache2
19600 www-data  20   0  224m  20m  11m S    1  0.5   0:00.73 apache2
19942 www-data  20   0  225m  21m  10m S    1  0.5   0:00.82 apache2
20232 www-data  20   0  222m  16m 8760 S    1  0.4   0:00.65 apache2
20243 www-data  20   0  223m  21m  11m S    1  0.5   0:00.57 apache2
20299 www-data  20   0  225m  20m   9m S    1  0.5   0:00.67 apache2
20441 www-data  20   0  225m  21m  10m S    1  0.5   0:00.57 apache2
21201 www-data  20   0  220m  12m 5148 S    1  0.3   0:00.19 apache2
21362 www-data  20   0  220m  12m 5032 S    1  0.3   0:00.17 apache2
21364 www-data  20   0  220m  12m 4916 S    1  0.3   0:00.14 apache2
21366 www-data  20   0  220m  12m 5124 S    1  0.3   0:00.22 apache2
21373 www-data  20   0  222m  14m 7060 S    1  0.4   0:00.26 apache2

Ecco alcuni strumenti per trovare l'attività del disco:

• iotop
• vmstat 1
• iostat 1
• lsof
• strace -e trace=open <application>
• strace -e trace=open -p <pid>

In ps auxfvedrai anche quali processi sono in modalità di sospensione del disco non interpretabile ( D) perché sono in attesa di I / O.

Alcuni giorni il carico aumenta per raggiungere 40 senza aumentare il numero di visitatori.

Potresti anche voler creare un backup e vedere se il disco rigido sta lentamente fallendo. Un hard disk generalmente inizia a rallentare prima che decada. Questo potrebbe anche spiegare l'alto carico.

L'output dall'alto suggerisce che il DBMS sta vivendo la maggior parte delle attese di I / O, quindi i problemi di ottimizzazione del database sono un ovvio candidato per indagare.

L'I / O in attesa su un server di database, in particolare su picchi di carico, è un indizio del fatto che il vostro DBMS potrebbe essere associato al disco (ovvero è necessario un sottosistema del disco più veloce) o potrebbe avere un problema di ottimizzazione. Probabilmente dovresti anche esaminare il profilo del tuo server di database, ad esempio ottenere una traccia di ciò che sta facendo e di quali query richiedono tempo.

Alcuni punti di partenza per la diagnosi dei problemi di ottimizzazione del database: -

• Trova le query che impiegano più tempo e osserva i piani di query. Vedi se qualcuno ha piani di query dispari come una scansione di tabelle dove non dovrebbe essere. Forse è necessario aggiungere un indice al database.

• I lunghi tempi di attesa delle risorse possono comportare l'espansione di alcuni pool di risorse chiave.

• Tempi di attesa I / O lunghi potrebbero comportare la necessità di un sottosistema di dischi più veloce.

• I volumi di log e dati sono su unità separate? I registri del database hanno molte piccole scritture sequenziali (essenzialmente si comportano come un buffer ad anello). Se si dispone di un carico di lavoro ad accesso casuale occupato che condivide gli stessi dischi dei registri, ciò influirà in modo sproporzionato sulla velocità effettiva della registrazione. Affinché una transazione del database esegua il commit delle voci del registro, deve essere scritta sul disco, quindi ciò comporterà un collo di bottiglia sull'intero sistema.
  
  Si noti che alcuni motori di archiviazione MySQL non utilizzano i log, quindi questo potrebbe non essere un problema nel tuo caso.

Nota a piè di pagina: sistemi di accodamento

I sistemi di accodamento (un modello statistico per la velocità effettiva) diventano iperbolicamente più lenti man mano che il sistema si avvicina alla saturazione. Per un'approssimazione di alto livello, un sistema saturato al 50% ha una lunghezza media della coda di 2. Un sistema saturo al 90% ha una lunghezza della coda di 10, un sistema saturato al 99% ha una lunghezza della coda di 100.

Pertanto, su un sistema vicino alla saturazione, piccoli cambiamenti nel carico possono comportare grandi cambiamenti nei tempi di attesa, in questo caso manifestandosi come tempo trascorso in attesa sull'I / O. Se la capacità I / O del sottosistema del disco è quasi satura, piccole variazioni nel carico possono comportare variazioni significative nei tempi di risposta.

Esegui iotopo atop -dDper vedere quali processi stanno eseguendo io. Utilizzare stracese è necessario uno sguardo più attento.

In entrambi gli schermi sembra che "mysqld" sia responsabile.

Devi vedere cosa sta facendo quel demone ... quali query sono in esecuzione.

Alcuni giorni il carico aumenta per raggiungere 40 senza aumentare il numero di visitatori.

Quello che stanno facendo gli utenti potrebbe essere significativo quanto il numero che sono effettivamente lì. Operazioni come la ricerca nel forum saranno più impegnative del semplice caricamento e visualizzazione di singoli thread o elenchi di thread.

Inoltre: stai eseguendo un server dedicato o un VPS? Se il tuo servizio non è su un server dedicato, le azioni delle app in esecuzione sullo stesso host avranno effetto poiché le VM con cui la VM condivide un host competeranno per una condivisione della risorsa I / O.

Come altri hanno sottolineato, strumenti come iotopti aiuteranno ad approfondire quali attività sono in attesa di risposte I / O e quali file accedono in quel momento.

Come dice Flip, sembra che il problema sia quello che sta facendo mysql.

Circa metà della memoria fisica viene attualmente utilizzata per la memorizzazione nella cache di I / O - il software del forum di solito genera molte query rapide che restituiscono un numero limitato di righe, con aree calde molto inclinate del disco - quindi c'è qualcosa di decisamente strano se il sistema sta spendendo così tanto tempo in attesa.

Vedo sempre un utilizzo della CPU / del disco simile quando eseguo query che aggiornano milioni di righe.

La media del carico elevato è conseguenza diretta dell'I / O.

Accendi la tua registrazione mysql per vedere se c'è un codice errato lì dentro / cambiare gli indici sarebbe d'aiuto. Analizzare le tue tabelle può aiutare (ma probabilmente non molto).

C.