wa (Esperando E / S) desde el comando superior es grande

Tengo un foro con muchos visitantes, algunos días la carga aumenta para llegar a 40 sin aumentar el número de visitantes. Como puede ver en la salida a continuación, el tiempo de espera es alto (57%). ¿Cómo encuentro la razón para eso?
El software del servidor es Apache, MySQL y PHP.

root@server:~# top
top - 13:22:08 up 283 days, 22:06,  1 user,  load average: 13.84, 24.75, 22.79
Tasks: 333 total,   1 running, 331 sleeping,   0 stopped,   1 zombie
Cpu(s): 20.6%us,  7.9%sy,  0.0%ni, 13.4%id, 57.1%wa,  0.1%hi,  0.9%si,  0.0%st
Mem:   4053180k total,  3868680k used,   184500k free,   136380k buffers
Swap:  9936160k total,    12144k used,  9924016k free,  2166552k cached

 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
23930 mysql     20   0  549m 122m 6580 S   90  3.1   4449:04 mysqld
17422 www-data  20   0  223m  20m  10m S    2  0.5   0:00.21 apache2
17555 www-data  20   0  222m  19m 9968 S    2  0.5   0:00.13 apache2
17264 www-data  20   0  225m  19m 8972 S    1  0.5   0:00.17 apache2
17251 www-data  20   0  220m  12m 4912 S    1  0.3   0:00.12 apache2

.

root@server:~# top
top - 13:39:59 up 283 days, 22:24,  1 user,  load average: 6.66, 10.39, 13.95
Tasks: 318 total,   1 running, 317 sleeping,   0 stopped,   0 zombie
Cpu(s): 13.6%us,  4.2%sy,  0.0%ni, 40.5%id, 40.6%wa,  0.2%hi,  0.8%si,  0.0%st
Mem:   4053180k total,  4010992k used,    42188k free,   119544k buffers
Swap:  9936160k total,    12160k used,  9924000k free,  2290716k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
23930 mysql     20   0  549m 122m 6580 S   44  3.1   4457:30 mysqld
19946 www-data  20   0  223m  21m  10m S    5  0.6   0:00.77 apache2
17316 www-data  20   0  226m  23m  11m S    1  0.6   0:01.76 apache2
17333 www-data  20   0  222m  21m  11m S    1  0.5   0:01.55 apache2
18212 www-data  20   0  225m  22m  11m S    1  0.6   0:01.58 apache2
19528 www-data  20   0  220m  13m 5480 S    1  0.3   0:00.63 apache2
19600 www-data  20   0  224m  20m  11m S    1  0.5   0:00.73 apache2
19942 www-data  20   0  225m  21m  10m S    1  0.5   0:00.82 apache2
20232 www-data  20   0  222m  16m 8760 S    1  0.4   0:00.65 apache2
20243 www-data  20   0  223m  21m  11m S    1  0.5   0:00.57 apache2
20299 www-data  20   0  225m  20m   9m S    1  0.5   0:00.67 apache2
20441 www-data  20   0  225m  21m  10m S    1  0.5   0:00.57 apache2
21201 www-data  20   0  220m  12m 5148 S    1  0.3   0:00.19 apache2
21362 www-data  20   0  220m  12m 5032 S    1  0.3   0:00.17 apache2
21364 www-data  20   0  220m  12m 4916 S    1  0.3   0:00.14 apache2
21366 www-data  20   0  220m  12m 5124 S    1  0.3   0:00.22 apache2
21373 www-data  20   0  222m  14m 7060 S    1  0.4   0:00.26 apache2

Aquí hay algunas herramientas para encontrar la actividad del disco:

• iotop
• vmstat 1
• iostat 1
• lsof
• strace -e trace=open <application>
• strace -e trace=open -p <pid>

En ps auxfverá también que los procesos están en el sueño son interpretables disco ( D), ya que están a la espera de E / S.

Algunos días la carga aumenta hasta llegar a 40 sin aumento del número de visitantes.

También puede crear una copia de seguridad y ver si el disco duro falla lentamente. Un disco duro generalmente comienza a disminuir antes de que fallezca. Esto también podría explicar la alta carga.

El resultado de la parte superior sugiere que el DBMS está experimentando la mayoría de las esperas de E / S, por lo que los problemas de ajuste de la base de datos son un candidato obvio para investigar.

La E / S en espera en un servidor de base de datos, particularmente en picos de carga, es una pista de que su DBMS podría estar vinculado al disco (es decir, necesita un subsistema de disco más rápido) o podría tener un problema de ajuste. Probablemente también debería analizar la creación de perfiles de su servidor de base de datos, es decir, obtener un rastro de lo que está haciendo y qué consultas están tomando el tiempo.

Algunos puntos de partida para diagnosticar problemas de ajuste de la base de datos: -

• Encuentre las consultas que requieren más tiempo y mire los planes de consulta. Vea si alguno tiene planes de consulta extraños, como un escaneo de tabla donde no debería estar. Tal vez la base de datos necesita un índice agregado.

• Los largos tiempos de espera de recursos pueden significar que se necesita expandir algún grupo de recursos clave.

• Los largos tiempos de espera de E / S pueden significar que necesita un subsistema de disco más rápido.

• ¿Están sus volúmenes de registro y datos en unidades separadas? Los registros de la base de datos tienen muchas escrituras secuenciales pequeñas (esencialmente se comportan como un buffer de anillo). Si tiene una carga de trabajo de acceso aleatorio ocupada que comparte los mismos discos que sus registros, esto afectará desproporcionadamente el rendimiento del registro. Para que una transacción de base de datos se confirme, las entradas de registro deben escribirse en el disco, por lo que esto creará un cuello de botella en todo el sistema.
  
  Tenga en cuenta que algunos motores de almacenamiento MySQL no usan registros, por lo que esto puede no ser un problema en su caso.

Nota al pie: sistemas de colas

Los sistemas de colas (un modelo estadístico para el rendimiento) se vuelven hiperbólicamente más lentos a medida que el sistema se acerca a la saturación. Para una aproximación de alto nivel, un sistema que está 50% saturado tiene una longitud promedio de cola de 2. Un sistema que está 90% saturado tiene una longitud de cola de 10, un sistema que está 99% saturado tiene una longitud de cola de 100.

Por lo tanto, en un sistema que está cerca de la saturación, los pequeños cambios en la carga pueden dar lugar a grandes cambios en los tiempos de espera, en este caso se manifiestan como el tiempo dedicado a esperar E / S. Si la capacidad de E / S de su subsistema de disco está casi saturada, pequeños cambios en la carga pueden provocar cambios significativos en los tiempos de respuesta.

Ejecute iotop, o atop -dD, para ver qué procesos están haciendo io. Úselo stracesi necesita una mirada más cercana.

En ambas pantallas, parece que "mysqld" es el responsable.

Necesitas ver qué está haciendo ese demonio ... qué consultas se están ejecutando.

Algunos días la carga aumenta hasta llegar a 40 sin aumento del número de visitantes.

Lo que están haciendo los usuarios podría ser tan significativo como el número que realmente están allí. Las operaciones como buscar en el foro serán más exigentes que simplemente cargar y ver hilos individuales o listas de hilos.

Además: ¿estás ejecutando en un servidor dedicado o un VPS? Si su servicio no está en un servidor dedicado, las acciones de las aplicaciones que se ejecutan en el mismo host tendrán un efecto ya que las máquinas virtuales con las que su VM comparte un host competirán por una parte del recurso de E / S.

Como otros han señalado, las herramientas como iotople ayudarán a profundizar en qué tareas se encuentran esperando respuestas de E / S y a qué archivos están accediendo en ese momento.

Como dice Flip, parece que el problema está relacionado con lo que está haciendo mysql.

Alrededor de la mitad de su memoria física se está utilizando actualmente para el almacenamiento en caché de E / S: el software del foro generalmente genera muchas consultas rápidas que devuelven un pequeño número de filas, con áreas de disco muy distorsionadas, por lo que definitivamente hay algo mal si el sistema está gastando tanto tiempo en espera

Solo veo el uso de CPU / disco así cuando ejecuto consultas que actualizan millones de filas.

El alto promedio de carga es consecuencia directa de la E / S.

Arranque su registro mysql para ver si hay un código incorrecto allí / cambiar los índices ayudaría. Analizar sus tablas puede ayudar (pero probablemente no mucho).

DO.