Los usuarios se quejan de que el sistema funciona lentamente cuando mysqldump está en progreso

La base de datos MYSQL (ibdata1) tiene un tamaño de 73 GB y está configurada para ejecutarse como un servidor de base de datos dedicado en Windows 2008 O / S para tablas INNODB. Estamos ejecutando la copia de seguridad usando mysqldump mysqldump --skip-opt --quick --single-transaction --create-options --extended-insert --disable-keys --add-drop-table --complete-insert - set-charset - compress --log-error = Proddb0635.err -u root -pjohndoe Proddb> \ devNas \ devNas \ sqlbackup \ LIVE \ db \ Proddb0635.sql

El archivo de respaldo Proddb0635.sql se almacena en un servidor separado del servidor de la base de datos. RAM es de 12 GB. El tamaño de la agrupación de almacenamiento intermedio INNODB es de 6 GB. La memoria adicional es de 32 MB. El tamaño de la memoria caché de consultas es de 2 GB. La longitud neta del búfer es de 16 M máx. tamaño de paquete 1 GB.

La versión de mysql es 5.0.67.

Cuando la copia de seguridad no se ejecuta, los usuarios están contentos con el rendimiento.

Cuando se ejecuta la copia de seguridad, la tasa de aciertos de la agrupación de almacenamientos intermedios INNODB es alta, cercana al 100%. No hay lecturas pendientes ni escrituras pendientes. innodb wait free es 0. El uso de la CPU no es alto mín. 9% a máx. 15% La tasa de aciertos de la caché de consultas es baja, aproximadamente 40% con o sin mysqlbackup en ejecución. Actualmente, el Administrador de tareas de Windows muestra que se están utilizando 10 GB de RAM. ¿Debo aumentar Query Cache con solo 2GB de RAM disponible? mysqlld-nt está tomando 9.2 GB de RAM y mysqldump está tomando 5 MB de RAM. Alos, señaló que el tamaño del archivo de volcado es el mismo en presencia o ausencia de la opción --compress.

¿Debo disminuir el tamaño de la agrupación de almacenamiento intermedio iNNODB?

Gracias

— dbachacha
fuente

Respuestas:

Hay un problema conocido en Windows, que cuando empuja un archivo grande a otro servidor, toda la memoria termina siendo asignada a la caché del sistema en lugar de los procesos del usuario. Puede consultar la sección Memoria física (MB) del administrador de tareas para ver cuánta memoria se asigna a la memoria caché del sistema.

Esto se puede resolver haciendo una copia de seguridad en un disco local y luego haciendo que la máquina remota extraiga ese archivo.

— mrdenny
fuente

Gracias mrdenny. Tenemos nuestros discos almacenados en SAN. ¿Eso también marca la diferencia?

— dbachacha

Es un problema sin importar cómo se presente el almacenamiento. Siendo que el almacenamiento es SAN, no hay necesidad de copiar los archivos a través de la red a otra máquina. Presente un nuevo LUN al servidor MySQL y luego realice una copia de seguridad en esa máquina. Si necesita llevar los archivos a otra máquina para realizar una copia de seguridad en cinta, use la SAN. Ajuste el LUN, presente la instantánea al servidor de respaldo, haga una copia de respaldo de los archivos y luego elimine la instantánea. Repite al día siguiente. Probablemente todo esto pueda ser programado.

— mrdenny

Su primera sugerencia: los números no cambiaron en la memoria caché del sistema. Con respecto a LUN, lo transmitiré a mis colegas que trabajan en el Equipo de redes y sistemas.

— dbachacha

Moví el script de respaldo para ejecutarlo en otro servidor y hay una mejora considerable. Además, encontramos que el código de la aplicación no reutilizaba una conexión simple, sino que se abría / cerraba en múltiples funciones agrupadas en una sola solicitud al servidor de la base de datos. Además, descubrí que una tarjeta NIC es compartida por los datos de respaldo y los datos transaccionales en línea. Por lo tanto, estamos planeando tener una NIC dedicada solo para respaldo. Muchas gracias.

— dbachacha

Aquí hay algunas ideas que tengo sobre mejorar el rendimiento de mysqldump, dadas sus circunstancias. Aquí está tu comando:

mysqldump --skip-opt --quick --single-transacción --create-options --extend-insert --disable-keys --add-drop-table --complete-insert --set-charset --compress - -log-error = Proddb0635.err -u root -pjohndoe Proddb> \ devNas \ devNas \ sqlbackup \ LIVE \ db \ Proddb0635.sql

Lo primero que noto es que estás redirigiendo la salida a un sistema de archivos. Dice 'devNas', así que voy a suponer que este es el almacenamiento conectado a la red . Soy fanático de NAS para las copias de seguridad, pero debe estar conectado a una NIC física separada del tráfico de producción . Es posible que no esté saturando el ancho de banda, pero aún así compiten. Esto va a ser más problemático debido a la bandera --quick, ya que vacía cada fila en lugar de mantenerla en la memoria.

Lo siguiente que veo es que has invocado: comprimir. Parece que está ejecutando mysql localmente ya que no usó el modificador -h. Esto puede usar CPU local que es innecesaria en este contexto. ¿Es necesario comprimir? Solo comprime datos entre el cliente mysqldump y el servidor mysql, no el contenido del archivo.

A continuación, veo que está utilizando el indicador --single-transacción. Esto causará CPU extra ya que se está probando en cada selección como parte de mysqldump.

Esto no tiene nada que ver con el rendimiento, pero está utilizando --disable-keys que solo funciona en MyISAM ( manual ).

Es posible que desee experimentar ejecutando mysqldump de forma remota desde un host fuera de línea y moviendo el archivo de volcado al NAS después de la finalización para sacar la mayor cantidad posible de esta operación.

— randomx
fuente

Sí, lo verifiqué con el administrador de redes y sistemas. Es almacenamiento conectado a la red. Puedo intentar mover mysqldump a un servidor diferente. Además, ahora tenía sentido para mí el uso de --compress. El manual decía que --compress funciona con el cliente y el servidor, pero lo puse para ver si hace alguna diferencia. Qué tipo de datos fluyen entre el cliente que ejecuta mysqldump y el servidor de base de datos mysql. Los datos fluyen entre el servidor de base de datos mysql y devNas. La documentación y el libro de MySQl Diseño y ajuste de bases de datos prefieren el uso de transacciones únicas para tablas INNODB.

— dbachacha

Me alegra que esto esté ayudando. Los mejores deseos.

— randomx

Aquí necesito ayuda para comprender el siguiente escenario: La base de datos mysql está en el Servidor A. mysqldump se ejecuta en el Servidor B que descarga los datos en el Servidor C. Tenemos una NIC dedicada del Servidor A al Servidor C. ¿Es esto correcto? No estaba seguro, así que anoche el mysqldump se estaba ejecutando en el Servidor A. Me gustaría ejecutarlo en un Servidor diferente para reducir la contención de la CPU.

— dbachacha

mysqldump es una 'utilidad de cliente', lo que significa que puede ejecutarla desde cualquier host que tenga privilegios para acceder a las tablas de la base de datos. La estrategia para usted sería ejecutar mysqldump desde el shell del servidor C dirigido a las tablas del servidor A. Por supuesto, tendrá que otorgar acceso desde el Servidor C al esquema que desea volcar.

— randomx

OBSERVACIÓN # 1

Aquí hay algo a tener en cuenta al realizar un mysqldump contra InnoDB.

Cualquier página sucia que exista en el InnoDB Buffer Pool debe primero ser vaciada al disco. Un mysqldump activará el vaciado de una tabla InnoDB que todavía tiene páginas sucias.

Hay una opción de servidor llamada innodb_max_dirty_pages_pct . El valor predeterminado es 75 es MySQL 5.5 y 90 en versiones de MySQL anteriores a 5.5. En un entorno de producción, está bien dejar este número en el valor predeterminado.

Para ver si tiene muchas páginas sucias en el InnoDB Buffer Pool, ejecute esto:

SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_pages_dirty';

Por cierto, una página es 16K como se muestra a partir de esto:

SHOW GLOBAL STATUS LIKE 'Innodb_page_size';

Cuando se trata de InnoDB y mysqldump, puede reducir este número en dos circunstancias.

CIRCUNSTANCIA 1: ajústelo permanentemente a 0

Simplemente agregue esto a my.ini:

[mysqld]
innodb_max_dirty_pages_pct=0

Esto mantendrá el InnoDB Buffer Pool delgado y medio. El paso de vaciar la tabla InnoDB que se está volcando será rápido porque algunas páginas sucias como sea posible (tal vez 0) necesitarán vaciarse antes de que mysqldump funcione en ella.

El único inconveniente es que si mysqldump desde una base de datos altamente traficada, puede haber un aumento menor en la E / S de escritura debido a que se vacía la página sucia con más frecuencia. Puede determinar si esto es así sin reiniciar mysql ejecutando esto:

SET GLOBAL innodb_max_dirty_pages_pct = 0;

Deje la configuración durante 12-24 horas, si el rendimiento de escritura es aceptable, está listo. Si no, configúrelo de nuevo con:

SET GLOBAL innodb_max_dirty_pages_pct = 90;

CIRCUNSTANCIA 2: configúrelo en 0 aproximadamente 1 hora antes de mysqldump

SET GLOBAL innodb_max_dirty_pages_pct = 0;

Ejecute mysqldump

SET GLOBAL innodb_max_dirty_pages_pct = 90;

OBSERVACIÓN # 2

Tienes --complete-insert como una opción mysqldump. Esto incrustará los nombres de columna en cada declaración INSERT antes de la cláusula VALUES. Incluso con --extended-insert, en cada lote de filas que se insertan los nombres de columna se envían al mysqldump. Puede reducir la cantidad de bytes enviados al mysqldump eliminando --complete-insert.

RECOMENDACIÓN

Si tiene otro servidor de Windows que se puede configurar como esclavo, realice los mysqldumps desde ese esclavo en lugar de hacerlo desde la máquina de producción.

— RolandoMySQLDBA
fuente

Gracias. Olvidé mencionar que los usuarios se quejan de que "guardar" lleva tiempo en lugar de leer. Implementaré su observación # 2 inmediatamente. Definitivamente me gusta su recomendación de tener un esclavo y luego tomar mysqldump de esclavo.

— dbachacha

innodb_buffer_pool_dirty_pages no era demasiado alto justo antes de que comenzara la copia de seguridad. Es alrededor de 9 a máx. 196. Master-Slave es una buena recomendación también.

— dbachacha