wa (In attesa di I/O) dal comando superiore è grande

Soluzione 1:

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>

Nel ps auxf vedrai anche quali processi sono in una sospensione del disco non interpretabile (D ) perché sono in attesa di I/O.

Alcuni giorni il carico aumenta fino a raggiungere i 40 senza aumento del numero di visitatori.

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

Soluzione 2:

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 da esaminare.

L'attesa di I/O su un server di database, in particolare sui picchi di carico, è un indizio del fatto che il tuo 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 la profilazione del tuo server di database, ovvero ottenere una traccia di ciò che sta facendo e quali query richiedono tempo.

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

• Trova le query che richiedono più tempo e osserva i piani di query. Verifica se qualcuno ha piani di query strani come una scansione della tabella dove non dovrebbe essere. Forse il database necessita di un indice aggiunto.

• I lunghi tempi di attesa delle risorse possono significare che alcuni pool di risorse chiave devono essere espansi.

• Lunghi tempi di attesa I/O possono significare che hai bisogno di un sottosistema disco più veloce.

• I tuoi volumi di log e dati sono su unità separate? I registri del database hanno molte piccole scritture sequenziali (essenzialmente si comportano come un ring buffer). 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 di database possa eseguire il commit, le voci di registro devono essere scritte su disco, quindi ciò creerà un collo di bottiglia sull'intero sistema.
  
  Tieni presente 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 il throughput) diventano iperbolicamente più lenti man mano che il sistema si avvicina alla saturazione. Per un'approssimazione di alto livello, un sistema saturo al 50% ha una lunghezza media della coda di 2. Un sistema saturo al 90% ha una lunghezza della coda pari a 10, un sistema saturo al 99% ha una lunghezza della coda pari a 100.

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

Soluzione 3:

Esegui iotop o atop -dD , per vedere quali processi stanno facendo io. Usa strace se hai bisogno di uno sguardo più da vicino.