Alta carga debido a la espera de E / S en Ubuntu 12.04 en la instancia EC2

Estoy usando el servidor Ubuntu 12.04, tengo problemas para encontrar la causa de la carga, he visto cambios en el tiempo de respuesta del servidor desde la semana pasada

después de leer la Solución de problemas de Linux, Parte I: Alta carga

Parece que no hay ningún problema con la CPU y la RAM, y esta carga puede estar relacionada con la carga vinculada a E / S mediante el topcomando que obtuve después de la salida

Aquí está 97.6%wa, la RAM es gratuita y no se utiliza ningún intercambio.

A continuación se muestra la salida del comando iostatque siembra que hay89% 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

También utilicé iotopque después del intervalo de corrección muestra el 99% de E / S, el disco escribe I observador como1266 KB/s

y

¿Es malo? como se reduce el tiempo de respuesta. ¿Qué está causando esto?

EDICIONES que otros solicitan

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

salida de 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

iotop -a

Sintonice su servicio mysql para evitar tocar el disco y tenga cuidado en su cola de postfix, puede tener muchos correos electrónicos en una cola sensible de E / S (es decir, iteraciones pequeñas diferidas con comportamiento de lectura aleatorio).

Su sistema de correo electrónico se ha utilizado como retransmisión para spammers.

Eche un vistazo a la documentación de postfix y restrinja el acceso de retransmisión a su MTA.

Editado después de obtener información adicional recopilada con iostat e iotop.
Su disco está 100% cargado ya que se está quedando sin IOPS disponibles: según iostat, tiene 50+ IOPS constantes (85 w / s - 35 fusionado w / s). Las instancias de EC2, especialmente las baratas, tienen un límite alto en IOPS sostenidas (en el rango de 30-50 IOPS).

Según la nueva salida de iotop, tanto mysql como bounce consumen una cantidad significativa de IOPS. Sin embargo, la salida de iotop parece no completa, o al menos mal ordenada. ¿Se puede volver a ejecutar "iotop -a" ordenando una vez por IOPS y otra vez por escritura en disco?

Respuesta original
Mi apuesta: el proceso de "rebote" está emitiendo muchas escrituras sincronizadas que ahogan el dispositivo de disco virtual ofrecido por Amazon (por cierto, ¿qué perfil está utilizando? Los discos EC2 tienen reglas bastante estrictas para E / S sostenidas frente a ráfagas).

De todos modos, identificar qué está quemando el ancho de banda de E / S puede ser algo difícil a veces. Si bien iotop es una muy buena herramienta, a veces no le brinda la información requerida. Necesitamos ir más profundo. Entonces, sigue estos consejos:

1. Primero, necesitamos identificar el tipo de E / S que se está procesando y el dispositivo de bloqueo afectado.
   Por favor, ejecute el siguiente comando: iostat -x -k 5 2. Por favor, informe ambos conjuntos de resultados.
2. Entonces, tenemos que identificar los procesos en espera de E / S .
   Cuando puede usar "top" para eso: ejecútelo, presione shift + f (F), luego w, luego ingrese, luego shift + r (R). Los primeros procesos serán en estado D o D + (es decir, esperando disco / red). Por favor, informe de nuevo la lista.
3. Use iotop para mostrar los valores de E / S acumulados para los procesos .
   Ejecutar iotop -adurante aproximadamente un minuto y pegar aquí la salida.

Un poco tarde, pero tuve el mismo problema en una máquina similar y descubrí que el problema era un montón de tablas MySQL corruptas. Como algunas de estas tablas tenían muchos datos, producían mucho tiempo de espera de E / S.

Mire /var/log/mysql/error.logo use mysqlcheckpara buscar y reparar datos corruptos.

Como se indicó anteriormente, es muy probable que su instancia EC2 venga con un límite de E / S o tal vez esté respaldado en un volumen estándar de Amazon EBS que simplemente no ofrece mucho E / S inteligente. Eche un vistazo a esta página : describe los diferentes tipos de volumen que ofrece Amazon.

Incluso si tiene el tipo lento de volumen, aún debería poder escribir razonablemente rápido, pero si su carga es aleatoria por naturaleza, como parece ser (cosas de SQL), es posible que desee actualizar el IOPS capacidad, ya que eso generalmente pone el límite superior en el rendimiento de SQL.

Entonces, según sus números, parece que podría quedarse sin IOPS con el almacenamiento estándar. Comprar un almacenamiento más rápido no es tan caro. Mira esto .

El disco puede estar en modo no DMA. Verifique el estado de DMA de la unidad. (comando hdparm)

Si no es eso, algo más puede generar muchas interrupciones. ¿Alguien recuerda los de la buena era de DOS?