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


9

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

Carga y uso de memoria

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

ingrese la descripción de la imagen aquí

y

ingrese la descripción de la imagen aquí

¿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

ingrese la descripción de la imagen aquí

iotop -a

ingrese la descripción de la imagen aquí


1
99% IOwait con 0 discos de lectura y escritura no se ve bien. Aquí se menciona serverfault.com/questions/426181/… , que las E / S podrían estar relacionadas no solo con la actividad del disco, sino también con la red. ¿Podría verificarlo con, por ejemplo, iftop (y otras herramientas también)?
Andrey Sapegin

@AndreySapegin agregó iftop
Sombrero de paja

Creo que el problema era con el disco en el que se desplegó AWS Instancia .. creé IAM de la instancia actual y puesto en marcha nuevas ejemplo utilizando .. Ahora que no hay ninguna carga extra en la E / S
Sombrero de paja

@StrawHat ¿Eso significa que crees que hubo algo mal con el disco en tu primera instancia?
sbrattla

@sbrattla No, creo. después de unos días apareció el mismo problema
Straw Hat

Respuestas:


2

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.


mover mysql a la instancia de RDS funcionará?
Straw Hat

1
Más o menos, el problema principal se debe a la gran cantidad de itens en una cola de postfix que se comen sus iops, puede ver con el 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
Sombrero de paja

postconf: warning: /etc/postfix/master.cf: unused parameter: smtpd_bind_address=127.0.0.1tengo estos erroresqshape deferred
Straw Hat

1
Creo que su postfix puede estar mal configurado, pero para su problema actual, mire cuántos correos electrónicos tiene /var/lib/postfix/deferred. Moverlos a la holdcola para una mayor investigación o limpieza.
fgbreel

1

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.

iostat -x -k 5 2 y también agregado en cuestión
Straw Hat

1

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.


0

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 .


-3

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?


EC2 es una plataforma de virtualización y utiliza discos virtuales. DMA no es el culpable aquí. De todos modos, una tormenta IRQ representa un costo para la CPU, no para el disco.
shodanshok

Sí e IRQ significa interrupciones.
Overmind

Yo diría que EC2 está tan alejado de ese tipo de problema como sea posible. La E / S está limitada por tipo de instancia, y al final por alguna solución SAN realmente costosa que tiene mucha capacidad.
MrMajestyk
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.