Entonces, tenemos un servidor que tiene picos aparentemente aleatorios en la E/S del disco, que suben al 99,x% en momentos aleatorios y sin razón obvia, se mantienen altos por un tiempo y luego vuelven a bajar. Esto no solía ser un problema, pero recientemente la E/S del disco se ha mantenido al 99% durante períodos prolongados, en algunos casos hasta 16 horas.
El servidor es un servidor dedicado, con 4 núcleos de CPU y 4 GB de RAM. Está ejecutando Ubuntu Server 14.04.2, ejecutando percona-server 5.6 y nada más importante. Se está monitoreando el tiempo de inactividad y tenemos una pantalla que muestra permanentemente CPU/RAM/E/S de disco para los servidores con los que tratamos. El servidor también recibe parches y mantenimiento periódicos.
Este servidor es el tercero de una cadena de réplicas y está ahí como una máquina de conmutación por error. El flujo de datos de MySQL es el siguiente.
Maestro --> Maestro/Esclavo --> Servidor de Problemas
Las 3 máquinas tienen especificaciones idénticas y están alojadas en la misma empresa. El servidor problemático está en un centro de datos diferente al primero y al segundo.
La herramienta 'iotop' nos muestra que la E/S del disco está siendo causada por el proceso 'jbd2/sda7-8'. Por lo que sabemos, esto maneja el registro en diario del sistema de archivos y el vaciado de cosas en el disco. Nuestra partición 'sda7' es '/var' y nuestra partición sda8 es /home. Nada debería leerse o escribirse en /home de forma regular. Al detener el servicio mysql, la E/S del disco vuelve inmediatamente a un nivel normal, por lo que estamos bastante seguros de que es percona el que está causando el problema, y esto coincidiría con que sea la partición /var, ya que aquí es donde se encuentra nuestro MySQL. reside el directorio de datos (/var/lib/mysql).
Usamos NewRelic para monitorear todos nuestros servidores, y cuando la E/S del disco aumenta, no podemos ver nada que pueda estar causándolo. El promedio de carga se sitúa en ~2. El uso de la CPU ronda el ~25%, lo que según NewRelic se debe a 'IO Wait' en lugar de a un proceso en particular.
Nuestro archivo de configuración mysql se generó mediante una combinación del asistente de configuración de Percona y algunas configuraciones necesarias para la aplicación de nuestros clientes, pero no es nada particularmente sofisticado.
configuración de mysql -http://pastebin.com/5iev4eNa
Hemos intentado lo siguiente para intentar resolver el problema:
Ejecuté mysqltuner.pl para ver si obviamente había algún problema. Los resultados son muy similares a los resultados de la misma herramienta en los otros 2 servidores de bases de datos y no cambian mucho entre usos.
Usé vmstat, iotop, iostat, pt-diskstats, fatrace, lsof, pt-stalk y probablemente algunos más, pero no saltó nada obvio.
Se modificó la variable 'innodb_flush_log_at_trx_commit'. Intenté configurarlo en 0, 1 y 2, pero ninguno pareció tener ningún efecto. Esto debería haber cambiado la frecuencia con la que MySQL enviaba transacciones a los archivos de registros.
Un 'mostrar lista de procesos completa' de mysql no es muy interesante cuando la E/S del disco es alta, solo muestra la lectura del esclavo desde el maestro.
Algunos de los resultados de las herramientas son obviamente bastante largos, por lo que proporcionaré enlaces de Pastebin y no pude copiar y pegar el resultado de iotop, por lo que proporcioné una captura de pantalla.
iotop
pt-diskstats:http://pastebin.com/ZYdSkCsL
Cuando la E/S del disco es alta, "vmstat 2" nos muestra que las cosas que se escriben se deben principalmente a "bo" (búfer agotado), que se correlaciona con el diario del disco (vaciado de búfer/RAM al disco).
“lsof -p mysql-pid” (lista de archivos abiertos de un proceso) nos muestra que los archivos que se escriben son en su mayoría archivos .MYI y .MYD en el directorio /var/lib/mysql, y master.info y relé- bin y archivos de registro de retransmisión. Incluso sin especificar el proceso mysql (por lo que cualquier archivo se escribe en todo el servidor), el resultado es muy similar (principalmente archivos MySQL, no mucho más). Esto me confirma que definitivamente lo está causando Percona.
Cuando la E/S del disco es alta, los "segundos_detrás_maestro" aumentan. Todavía no estoy seguro de en qué dirección suceden. “Secons_behind_master” también salta temporalmente de valores normales a valores arbitrariamente grandes y luego vuelve a la normalidad casi de inmediato; algunas personas han sugerido que esto podría deberse a problemas de red.
'mostrar estado de esclavo' -http://pastebin.com/Wj0tFina
El controlador RAID (3ware 8006) no tiene capacidad de almacenamiento en caché; Alguien también sugirió que el rendimiento deficiente del almacenamiento en caché podría estar causando el problema. El controlador tiene firmware, versión, revisión, etc. idénticos a las tarjetas de otros servidores para el mismo cliente (aunque sean servidores web), por lo que estoy bastante seguro de que no es culpa suya. También realicé verificaciones de la matriz, que resultaron bien. También tenemos el script de comprobación de RAID que nos habría alertado de cualquier cambio.
Las velocidades de la red son terribles en comparación con las del segundo servidor de base de datos, así que creo que tal vez se trate de un problema de red. Esto también se correlaciona con picos en el ancho de banda justo antes de que la E/S del disco aumente. Sin embargo, incluso cuando la red "aumenta", no genera una gran cantidad de tráfico, sólo relativamente alto en comparación con el promedio.
Velocidades de red (generadas mediante iPerf en una instancia de AWS)
Servidor con problemas: 0,0-11,3 s 2,25 MBytes 1,67 Mbits/s Segundo servidor: 0,0-10,0 s 438 MBytes 366 Mbits/s
Aparte de ser lenta, la red parece estar bien. Sin pérdida de paquetes, pero algunos saltos lentos entre servidores
Estaré encantado de proporcionar también resultados de cualquier comando relevante, pero solo puedo agregar 2 enlaces a esta publicación porque soy un usuario nuevo :(
EDITARNos pusimos en contacto con nuestro proveedor de alojamiento con respecto a este problema y tuvieron la amabilidad de cambiar los discos duros por SSD del mismo tamaño. Reconstruimos el RAID en estos SSD, pero lamentablemente el problema persiste.
Respuesta1
¿Qué versión del servidor MySQL utilizas? Después de 5.5, puede usar performance_schema para obtener estadísticas en tiempo real de la base de datos. Empezaría a consultar el
table_io_waits_summary_by_table
table_io_waits_summary_by_table
table_lock_waits_summary_by_table
para ver qué está pasando exactamente.
Otra solución sería si verifica el uso del grupo de búfer, no es posible que haya páginas inactivas que deban moverse a la memoria.
Respuesta2
La mejor manera de atacarlo es mirarhttp://www.brendangregg.com/linuxperf.htmly sigue el consejo de Brendan.
Específicamente, desea su herramienta iosnoop que le dirá quién accede más al almacenamiento. Pero te harás un gran favor si lo lees para conocer su proceso de pensamiento y sus metodologías, ya que eso te beneficiaría mucho a largo plazo.