Carico elevato dovuto all'attesa di I / O in Ubuntu 12.04 sull'istanza EC2

9

Sto usando Ubuntu server 12.04, avendo difficoltà a trovare la causa del carico, ho visto cambiamenti nei tempi di risposta del server dalla scorsa settimana

dopo aver letto la risoluzione dei problemi di Linux, parte I: carico elevato

Sembra che non ci siano problemi con CPU e RAM, e questo carico può essere correlato al carico associato a I / O usando il topcomando che ho ricevuto in uscita

Caricamento e utilizzo della memoria

Eccola 97.6%wa, la RAM è gratuita e non viene utilizzata alcuna sostituzione.

Segue l'output del comando iostatche semina che ci sia89% iowait

ubuntu@ip-my-sys-ubuntu:~$ iostat
Linux 3.2.0-58-virtual (ip-172-31-6-203)    02/19/2015  _x86_64_    (1 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3.05    0.01    3.64   89.50    3.76    0.03

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
xvdap1           69.91         3.81       964.37     978925  247942876

Ho anche usato iotopche dopo che l'intervallo di correzione mostra il 99% di I / O, il disco scrive come osservatore1266 KB/s

inserisci qui la descrizione dell'immagine

e

inserisci qui la descrizione dell'immagine

È male? poiché i tempi di risposta sono ridotti. cosa sta causando questo?

MODIFICHE chieste da altri

iftop O / P

                  12.5kb             25.0kb            37.5kb             50.0kb       62.5kb
└─────────────────┴──────────────────┴─────────────────┴──────────────────┴──────────────────
ip-12-1-1-111.ap-southeast-1.  => 115.231.218.130                      0b   2.04kb   522b
                                 <=                                      0b   1.53kb   393b
ip-112-1-1-111.ap-southeast-1.  => 62.snat-111-91-22.hns.net.in      1.52kb  1.52kb  1.72kb
                                 <=                                    208b    208b    262b
ip-112-1-1-111.ap-southeast-1.  => static-mum-120.63.141.177.mtnl.      0b    480b    240b
                                 <=                                      0b    350b    175b
ip-112-1-1-111.ap-southeast-1.  => ip-112-11-1-1.ap-southeast-1.co      0b    118b    178b
                                 <=                                      0b    210b    292b
ip-112-1-1-111.ap-southeast-1.  => static-mum-120.63.194.119.mtnl.      0b      0b    240b
                                 <=                                      0b      0b    175b

TX:             cum:    123kB   peak:   3.72kb               rates:   1.67kb  2.02kb  1.78kb
RX:                    51.5kB           4.88kb                        1.19kb   989b    918b
TOTAL:                  174kB           8.60kb                        2.86kb  2.98kb  2.68kb

uscita di iostat -x -k 5 2

ubuntu@ip-111-11-1-111:~$ iostat -x -k 5 2
Linux 3.2.0-58-virtual (ip-111-11-1-111)        03/04/2015      _x86_64_        (1 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3.75    0.01    4.74   22.72    4.06   64.71

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
xvdap1            0.00   263.80    0.42  109.42     7.28  1572.36    28.76     1.92   17.52   17.57   17.52   2.31  25.39

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           8.97    0.00    4.77   76.34    9.92    0.00

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
xvdap1            0.00    35.69    0.00   85.88     0.00   438.93    10.22   137.55 1612.71    0.00 1612.71  11.11  95.42

@shodanshok punto 2

inserisci qui la descrizione dell'immagine

iotop -a

inserisci qui la descrizione dell'immagine

— Cappello di paglia
fonte

1

99% IOwait con 0 lettura e scrittura del disco non ha un bell'aspetto. Qui serverfault.com/questions/426181/… si dice che l'I / O potrebbe essere correlato non solo all'attività del disco, ma anche alla rete. Potresti verificarlo con, ad esempio, iftop (e anche altri strumenti)?

— Andrey Sapegin,

@AndreySapegin ha aggiunto iftop

— Straw Hat il

Penso che il problema riguardasse il disco su cui è stata distribuita l'istanza AWS .. Ho creato l'AMI dell'istanza corrente e ho lanciato la nuova istanza usando quello .. Ora non vi è alcun carico aggiuntivo sull'I / O

— Cappello di paglia

@StrawHat significa che pensi che ci sia qualcosa di sbagliato nel disco nella tua prima istanza?

— sbrattla,

@sbrattla No, penso. dopo pochi giorni è emerso lo stesso problema

— Cappello di paglia,

2

Ottimizza il tuo servizio mysql per evitare di toccare il disco e fare attenzione nella coda postfix, potresti avere molte e-mail in una coda sensibile I / O (cioè differita, piccoli elementi con comportamento di lettura casuale).

Il tuo sistema di posta elettronica è stato utilizzato come relay per gli spammer.

Dai un'occhiata alla documentazione postfix e limita l'accesso di inoltro al tuo MTA.

— fgbreel
fonte

spostare MySQL all'istanza RDS funzionerà?

— Cappello di paglia

1

In un certo senso, il problema principale è a causa dell'elevato numero di iten in una coda postfix che mangia i tuoi iops, puoi vedere con il qshape deferredcomando.

— fgbreel

postconf: warning: /etc/postfix/main.cf: unused parameter: virtual_mailbox_limit_maps=proxy:mysql:/etc/zpanel/configs/postfix/mysql-virtual_mailbox_limit_maps.cf

— Cappello di paglia

postconf: warning: /etc/postfix/master.cf: unused parameter: smtpd_bind_address=127.0.0.1ha ricevuto questi erroriqshape deferred

— Cappello di paglia

1

Penso che il tuo postfix possa essere configurato in modo errato, ma per il tuo problema attuale, dai un'occhiata a quante email hai /var/lib/postfix/deferred. Spostali in holdcoda per ulteriori accertamenti o pulizie.

— fgbreel

1

Modificato dopo ulteriori informazioni raccolte usando iostat e iotop
Il tuo disco è caricato al 100% man mano che si esauriscono gli IOPS disponibili: secondo iostat, hai un IOPS costante di oltre 50 (85 w / s - 35 uniti). Le istanze EC2, in particolare quelle a basso costo, hanno un forte limite agli IOPS sostenuti (nell'intervallo 30-50 IOPS).

Secondo la nuova uscita iotop, sia mysql che bounce stanno consumando una quantità significativa di IOPS. Tuttavia, l'output di iotop sembra non completo, o almeno mal ordinato. È possibile rieseguire l'ordinamento "iotop -a" una volta per IOPS e un'altra per scrittura su disco?

Risposta originale La
mia scommessa: il processo di "rimbalzo" sta emettendo molte scritture sincronizzate che soffocano il dispositivo a disco virtuale offerto da Amazon (a proposito, quale profilo stai usando? I dischi EC2 hanno regole abbastanza rigide per l'I / O continuo vs burst).

Ad ogni modo, identificare ciò che sta bruciando la larghezza di banda I / O può essere alquanto difficile a volte. Mentre iotop è uno strumento molto valido, a volte non ti fornisce le informazioni richieste. Dobbiamo andare più a fondo. Quindi, segui questi consigli:

Innanzitutto, dobbiamo identificare il tipo di I / O in elaborazione e il dispositivo a blocchi interessato.
Si prega di eseguire il seguente comando: iostat -x -k 5 2. Si prega di segnalare entrambi i set di risultati.
Poi, abbiamo bisogno di identificare i processi in attesa di I / O .
Quando puoi usare "top" per quello: lanciarlo, premi maiusc + f (F), quindi w, quindi premi Invio, quindi Maiusc + r (R). I primi processi saranno quelli in stato D o D + (ovvero: in attesa di disco / rete). Si prega di riportare indietro l'elenco.
Utilizzare iotop per mostrare i valori di I / O accumulati per i processi .
Esegui iotop -aper circa un minuto e incolla qui l'output.

— shodanshok
fonte

iostat -x -k 5 2 e anche aggiunto in questione

— Cappello di paglia

1

Un po 'tardi, ma ho avuto lo stesso problema su una macchina simile e ho scoperto che il problema era un mucchio di tabelle MySQL corrotte. Poiché alcune di queste tabelle contenevano molti dati, producevano molti tempi di attesa I / O.

Guarda /var/log/mysql/error.logo usa mysqlcheckper trovare e riparare i dati danneggiati.

— ojovirtual
fonte

0

Come detto sopra, è molto probabile che la tua istanza EC2 sia dotata di un limite massimo di I / O o forse sia supportata su un volume Amazon EBS Standard che semplicemente non fornisce molto I / O. Dai un'occhiata a questa pagina : descrive i diversi tipi di volume offerti da Amazon.

Anche se hai il tipo di volume lento, dovresti comunque essere in grado di scriverlo abbastanza velocemente, ma se il tuo carico è casuale per natura, come potrebbe sembrare (roba SQL), potresti voler aggiornare gli IOPS capacità, poiché di solito pone il limite superiore sulle prestazioni SQL.

Quindi, dai tuoi numeri, sembrerebbe che tu possa rimanere senza IOPS usando l'archiviazione standard. L'acquisto di spazio di archiviazione più veloce non è così costoso. Dai un'occhiata a questo .

— MrMajestyk
fonte

-3

Il disco potrebbe essere in modalità non DMA. Verificare lo stato DMA dell'unità. (comando hdparm)

In caso contrario, qualcos'altro potrebbe generare molti interrupt. Qualcuno ricorda quelli della buona vecchia era DOS?

— Unica Mente
fonte

EC2 è una piattaforma di virtualizzazione e utilizza dischi virtuali. DMA non è il colpevole qui. Ad ogni modo, una tempesta IRQ rappresenta un tributo per la CPU, non per il disco.

— shodanshok,

Sì e IRQ significa interruzioni.

— Overmind

EC2 è il più lontano possibile da quel tipo di problema, direi. L'I / O è limitato dal tipo di istanza e alla fine da una soluzione SAN davvero costosa che ha molta capacità.

— Mr Majestyk,