9 votos

Alta carga debido a la e/S de esperar en Ubuntu 12.04 en la instancia de EC2

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

después de la lectura de Linux Solución de problemas, Parte I: Carga Alta

Parece que no hay ningún problema con la CPU y la RAM, y esta carga puede estar relacionado con el I/O-bound de carga mediante el uso de top comando conseguí siguiente resultado

Load and memory usage

Aquí es 97.6%wa , la memoria RAM es gratis y sin swap utilizado .

La siguiente es la salida del comando iostat que las hembras que no hay 89% 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 usé iotop que después de fijar el intervalo de muestra 99 %de e/S, las escrituras en Disco me observador como 1266 KB/s

enter image description here

y

enter image description here

Es que es malo? como el tiempo de respuesta es baja. cuál es la causa de esto?

Las EDICIONES que se hacen por los demás

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

enter image description here

iotop-un

enter image description here

2voto

fgbreel Puntos 479

Sintonice su servicio de mysql para evitar tocar en el disco y ver en tu postfix cola, usted puede tener un montón de mensajes de correo electrónico en un I/O sensibles a la cola (es decir, en diferido, a las pequeñas itens con la lectura aleatoria de comportamiento).

Su sistema de correo electrónico se han utilizado como relevo para los spammers.

Echa un vistazo a postfix documentación y restringir el acceso de relevo a su MTA.

1voto

shodanshok Puntos 2644

Editado después de la información adicional recopilada mediante iostat y iotop
El disco es 100% cargado como se ejecuta fuera de la disposición de IOPS: como por iostat, tiene una constante de 50+ IOPS (85 w/s - 35 fusionado w/s). Las instancias de EC2, especialmente barato, tiene una pac fuerte sostenida de IOPS (en el rango de 30-50 IOPS).

Según la nueva iotop de salida, tanto de mysql y de rebote está comiendo significativo de la cantidad de IOPS. Sin embargo, iotop la salida no parece completa, o mal ordenados al menos. Puede volver a ejecutar "iotop-una" ordenación de una vez por IOPS y otro tiempo de escritura de disco?

Respuesta Original
Mi apuesta: el "rebote" del proceso es la emisión de muchos sincronizado escribe que ahogan el dispositivo de disco virtual que ofrece Amazon (por cierto, ¿qué perfil está utilizando? EC2 discos tienen bastante estrictas reglas sostenido vs ráfaga de e/S).

De todos modos, identificar lo que es la quema de e/S de ancho de banda puede ser un poco difícil a veces. Mientras iotop es una herramienta muy buena, a veces no te dan la información necesaria. Tenemos que ir más profundo. Por lo tanto, siga estos consejos:

  1. En primer lugar, debemos identificar el tipo de I/O procesado y el afectado dispositivo de bloque.
    Por favor, ejecute el siguiente comando: iostat -x -k 5 2. Por favor, informe de resultados conjuntos.
  2. Entonces, tenemos que identificar los procesos en espera de I/O.
    Cuando se puede utilizar "top" para que: lanzamiento, presione mayús+f (F), entonces w, a continuación, enter, a continuación, mayús+r (R). El primero de los procesos será el D o D+ estado (es decir: a la espera de disco y red). Por favor, informe de la lista.
  3. Uso iotop para mostrar el acumulado de los valores de e/S para los procesos.
    Ejecutar iotop -a durante un minuto y pega aquí la salida.

1voto

ojovirtual Puntos 191

Un poco tarde, pero tuve el mismo problema en una máquina similar y encontró que el problema era un montón de corruptos de tablas de MySQL. Como algunas de estas mesas había una gran cantidad de datos, se produjo una gran cantidad de e/S de tiempo de espera.

Mira /var/log/mysql/error.log o utilización mysqlchecka la búsqueda y reparación de datos dañados.

0voto

MrMajestyk Puntos 515

Como se indicó anteriormente, es muy probable que la instancia de EC2 viene con un IO tapa o tal vez es respaldado en un Amazon EBS Estándar de volumen que simplemente no entrega mucho IO sabia. Tiene una mirada que esta página - se describe el volumen de los distintos tipos de Amazon ofrece.

Incluso si usted tiene el lento clase de volumen, usted debe ser capaz de escribir razonablemente rápido, pero si su carga es aleatorio por naturaleza, como parece que puede ser (SQL cosas), puede que desee actualizar los IOPS de la capacidad, ya que por lo general pone el límite superior de rendimiento de SQL.

Así que - a partir de sus números, parece que se acabe de IOPS utilizando el estándar de almacenamiento. Comprar más rápido de almacenamiento no es tan caro. Eche un vistazo a esto.

-3voto

Overmind Puntos 223

El disco tal vez no están en modo DMA. Por favor, compruebe DMA estado de la unidad. (comando hdparm)

Si no se que, algo más se puede generar una gran cantidad de interrupciones. Alguien se acuerda de los buenos viejos época de DOS ?

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: