Hoja de trucos de rendimiento de MySQL

MySQL es extenso y tiene muchas áreas para optimizar y modificar para obtener el rendimiento deseado. Algunos cambios se pueden realizar dinámicamente, otros requieren un reinicio del servidor. Es bastante común encontrar una instalación de MySQL con una configuración predeterminada, aunque esta última puede no ser apropiada per se según su carga de trabajo y configuración.

Estas son las áreas clave de MySQL que he tomado de diferentes fuentes expertas en el mundo de MySQL, así como nuestras propias experiencias aquí en Variousnines. Este blog le serviría como hoja de trucos para ajustar el rendimiento y hacer que su MySQL vuelva a ser excelente :-)

Echemos un vistazo a estos describiendo las áreas clave en MySQL.

Variables del sistema

MySQL tiene muchas variables que puede considerar cambiar. Algunas variables son dinámicas, lo que significa que se pueden configurar mediante la instrucción SET. Otros requieren un reinicio del servidor, después de configurarlos en el archivo de configuración (por ejemplo, /etc/my.cnf, etc/mysql/my.cnf). Sin embargo, repasaré las cosas comunes que son bastante comunes de ajustar para optimizar el servidor.

sort_buffer_size

Esta variable controla el tamaño de su búfer de clasificación de archivos, lo que significa que cada vez que una consulta necesita ordenar las filas, el valor de esta variable se usa para limitar el tamaño que debe asignarse. Tenga en cuenta que esta variable es por consulta que se procesa (o por conexión), lo que significa que sería una memoria hambrienta cuando configura esto más alto y si tiene múltiples conexiones que requieren ordenar sus filas. Sin embargo, puede controlar sus necesidades comprobando la variable de estado global Sort_merge_passes. Si este valor es grande, debería considerar aumentar el valor de la variable de sistema sort_buffer_size. De lo contrario, llévalo al límite moderado que necesites. Si configura esto demasiado bajo o si tiene consultas grandes para procesar, el efecto de ordenar sus filas puede ser más lento de lo esperado porque los datos se recuperan aleatoriamente haciendo inmersiones en el disco. Esto puede causar una degradación del rendimiento. No obstante, lo mejor es que arregles tus dudas. De lo contrario, si su aplicación está diseñada para extraer consultas grandes y requiere clasificación, entonces es eficiente usar herramientas que manejen el almacenamiento en caché de consultas como Redis. De forma predeterminada, en MySQL 8.0, el valor actual establecido es 256 KiB. Establezca esto en consecuencia solo cuando tenga consultas que utilicen mucho o ordenen llamadas.

leer_tamaño_búfer

La documentación de MySQL menciona que para cada solicitud que realiza un escaneo secuencial de una tabla, asigna un búfer de lectura. La variable de sistema read_buffer_size determina el tamaño del búfer. También es útil para MyISAM, pero esta variable también afecta a todos los motores de almacenamiento. Para las tablas de MEMORIA, se usa para determinar el tamaño del bloque de memoria.

Básicamente, cada subproceso que realiza un escaneo secuencial de una tabla MyISAM asigna un búfer de este tamaño (en bytes) para cada tabla que escanea. También se aplica a todos los motores de almacenamiento (que incluye InnoDB), por lo que es útil para consultas que ordenan filas usando ORDER BY y almacenan en caché sus índices en un archivo temporal. Si realiza muchos escaneos secuenciales, inserte de forma masiva en tablas de partición, almacene en caché los resultados de las consultas anidadas y luego considere aumentar su valor. El valor de esta variable debe ser un múltiplo de 4 KB. Si se establece en un valor que no es un múltiplo de 4 KB, su valor se redondeará al múltiplo de 4 KB más cercano. Tenga en cuenta que establecer esto en un valor más alto consumirá una gran parte de la memoria de su servidor. Sugiero no usar esto sin una evaluación comparativa y un control adecuados de su entorno.

leer_tamaño_búfer_rnd_

Esta variable se ocupa de la lectura de filas de una tabla MyISAM en orden después de una operación de clasificación de claves, las filas se leen a través de este búfer para evitar búsquedas en el disco. La documentación dice que, al leer filas en una secuencia arbitraria o de una tabla MyISAM en orden después de una operación de clasificación de claves, las filas se leen a través de este búfer (y se determinan a través de este tamaño de búfer) para evitar búsquedas de disco. Establecer la variable en un valor grande puede mejorar bastante el rendimiento de ORDER BY. Sin embargo, este es un búfer asignado para cada cliente, por lo que no debe establecer la variable global en un valor grande. En su lugar, cambie la variable de sesión solo desde aquellos clientes que necesitan ejecutar consultas grandes. Sin embargo, debe tener en cuenta que esto no se aplica a MariaDB, especialmente cuando se aprovecha MRR. MariaDB usa mrr_buffer_size mientras que MySQL usa read_buffer_size read_rnd_buffer_size.

join_buffer_size

Por defecto, el valor es de 256K. El tamaño mínimo del búfer que se utiliza para exploraciones de índice simple, exploraciones de índice de rango y uniones que no utilizan índices y, por lo tanto, realizan exploraciones de tabla completa. También lo utiliza la optimización BKA (que está desactivada de forma predeterminada). Aumente su valor para obtener combinaciones completas más rápidas cuando no sea posible agregar índices. Sin embargo, la advertencia podría ser problemas de memoria si configura esto demasiado alto. Recuerde que se asigna un búfer de combinación para cada combinación completa entre dos tablas. Para una combinación compleja entre varias tablas para las que no se utilizan índices, es posible que se necesiten varios búfer de combinación. Es mejor dejarlo bajo globalmente y establecerlo alto en las sesiones (mediante el uso de la sintaxis SET SESSION) que requieren uniones completas grandes. En plataformas de 64 bits, Windows trunca los valores superiores a 4 GB a 4 GB-1 con una advertencia.

max_heap_table_size

Este es el tamaño máximo en bytes para las tablas de MEMORIA creadas por el usuario que pueden crecer. Esto es útil cuando su aplicación se ocupa de las tablas del motor de almacenamiento de MEMORIA. Establecer la variable mientras el servidor está activo no tiene efecto en las tablas existentes a menos que se vuelvan a crear o se modifiquen. El menor de max_heap_table_size y tmp_table_size también limita las tablas internas en memoria. Esta variable también se combina con tmp_table_size para limitar el tamaño de las tablas internas en memoria (esto difiere de las tablas creadas explícitamente como Engine=MEMORY ya que solo aplica max_heap_table_size), el menor se aplica entre los dos.

tmp_table_size

El tamaño más grande para tablas temporales en memoria (no tablas MEMORIA), aunque si max_heap_table_size es menor, se aplicará el límite inferior. Si una tabla temporal en memoria supera el límite, MySQL la convierte automáticamente en una tabla temporal en disco. Aumente el valor de tmp_table_size (y max_heap_table_size si es necesario) si realiza muchas consultas GROUP BY avanzadas y tiene mucho espacio de memoria disponible. Puede comparar el número de tablas temporales internas en disco creadas con el número total de tablas temporales internas creadas comparando los valores de las variables Created_tmp_disk_tables y Created_tmp_tables. En ClusterControl, puede monitorear esto a través de Dashboard -> Gráfico de objetos temporales.

tabla_abierta_caché

Puede aumentar el valor de esta variable si tiene una gran cantidad de tablas a las que se accede con frecuencia en su conjunto de datos. Se aplicará a todos los subprocesos, es decir, por conexión. El valor indica el número máximo de tablas que el servidor puede mantener abiertas en cualquier instancia de caché de tablas. Aunque aumentar este valor aumenta la cantidad de descriptores de archivo que mysqld requiere, por lo que también podría considerar verificar su valor open_files_limit o verificar qué tan grande es el límite SOFT y HARD establecido en su sistema operativo * nix. Puede monitorear esto si necesita aumentar el caché de la tabla al verificar la variable de estado Opened_tables. Si el valor de Opened_tables es grande y no usa FLUSH TABLES con frecuencia (lo que obliga a cerrar y reabrir todas las tablas), entonces debe aumentar el valor de la variable table_open_cache. Si tiene un valor pequeño para table_open_cache y se accede con frecuencia a una gran cantidad de tablas, esto puede afectar el rendimiento de su servidor. Si nota muchas entradas en la lista de procesos de MySQL con el estado "Abriendo tablas" o "Cerrando tablas", entonces es hora de ajustar el valor de esta variable, pero tome nota de la advertencia mencionada anteriormente. En ClusterControl, puede verificar esto en Paneles -> Estado de caché abierto de tabla o Paneles -> Tablas abiertas. Puede consultarlo aquí para obtener más información.

table_open_cache_instances

Establecer esta variable ayudaría a mejorar la escalabilidad y, por supuesto, el rendimiento, lo que reduciría la contención entre sesiones. El valor que establezca aquí limita el número de instancias de caché de tablas abiertas. La caché de tablas abiertas se puede dividir en varias instancias de caché más pequeñas de tamaño table_open_cache/table_open_cache_instances. Una sesión necesita bloquear solo una instancia para acceder a ella para declaraciones DML. Esto segmenta el acceso a la memoria caché entre las instancias, lo que permite un mayor rendimiento para las operaciones que utilizan la memoria caché cuando hay muchas sesiones que acceden a las tablas. (Las declaraciones DDL aún requieren un bloqueo en todo el caché, pero tales declaraciones son mucho menos frecuentes que las declaraciones DML). Se recomienda un valor de 8 o 16 en sistemas que usan 16 o más núcleos de manera rutinaria.

caché_definición_tabla

Definiciones de tablas de caché, es decir, aquí es donde CREAR TABLA se almacenan en caché para acelerar la apertura de tablas y solo una entrada por tabla. Sería razonable aumentar el valor si tiene una gran cantidad de tablas. La memoria caché de definición de tabla ocupa menos espacio y no utiliza descriptores de archivo, a diferencia de la memoria caché de tabla normal. Peter Zaitsev de Percona sugiere probar la configuración de la siguiente fórmula,

The number of user-defined tables + 10% unless 50K+ tables

Pero tenga en cuenta que el valor predeterminado se basa en la siguiente fórmula limitada a un límite de 2000.

MIN(400 + table_open_cache / 2, 2000)

Entonces, en caso de que tenga una mayor cantidad de tablas en comparación con el valor predeterminado, entonces es razonable que aumente su valor. Tenga en cuenta que con InnoDB, esta variable se usa como un límite suave de la cantidad de instancias de tablas abiertas para la memoria caché del diccionario de datos. Aplicará el mecanismo LRU una vez supere el valor actual de esta variable. El límite ayuda a abordar situaciones en las que se utilizarían cantidades significativas de memoria para almacenar en caché instancias de tablas que se utilizan con poca frecuencia hasta el próximo reinicio del servidor. Por lo tanto, las instancias de tablas primarias y secundarias con relaciones de clave externa no se colocan en la lista de LRU y podrían imponer un límite superior al definido por table_definition_cache y no están sujetas a desalojo en la memoria durante LRU. Además, table_definition_cache define un límite suave para la cantidad de espacios de tabla de archivo por tabla de InnoDB que se pueden abrir al mismo tiempo, que también está controlado por innodb_open_files y, de hecho, se usa la configuración más alta entre estas variables, si ambas están configuradas . Si no se establece ninguna variable, se utiliza table_definition_cache, que tiene un valor predeterminado más alto. Si el número de identificadores de archivos de espacios de tablas abiertos excede el límite definido por table_definition_cache o innodb_open_files, el mecanismo LRU busca en la lista de LRU de archivos de espacios de tablas los archivos que están completamente vaciados y que no se están extendiendo actualmente. Este proceso se realiza cada vez que se abre un nuevo tablespace. Si no hay espacios de tabla "inactivos", no se cierra ningún archivo de espacio de tabla. Así que ten esto en cuenta.

paquete_máximo_permitido

Este es el tamaño máximo por conexión de una consulta SQL o una fila devuelta. El valor se incrementó por última vez en MySQL 5.6. Sin embargo, en MySQL 8.0 (al menos en 8.0.3), el valor predeterminado actual es 64 MiB. Puede considerar ajustar esto si tiene filas de BLOB grandes que deben extraerse (o leerse); de lo contrario, puede dejar esta configuración predeterminada en 8.0, pero en versiones anteriores, el valor predeterminado es 4 MiB, por lo que puede ocuparse de eso en caso de que encuentra el error ER_NET_PACKET_TOO_LARGE. El paquete más grande posible que se puede transmitir hacia o desde un servidor o cliente MySQL 8.0 es de 1 GB.

máx_conexiones

Este es el número de conexiones permitidas para su servidor MySQL. Si encuentra el error en MySQL "Demasiadas conexiones", podría considerar configurarlo más alto. De forma predeterminada, el valor de 151 no es suficiente, especialmente en una base de datos de producción, y teniendo en cuenta que tiene mayores recursos del servidor (no desperdicie los recursos de su servidor, especialmente si es un servidor MySQL dedicado). Sin embargo, debe tener suficientes descriptores de archivo; de lo contrario, se quedará sin ellos. En ese caso, considere ajustar su límite SOFT y HARD de sus sistemas operativos *nix y establezca un valor más alto de open_files_limit en MySQL (5000 es el límite predeterminado). Tenga en cuenta que es muy frecuente que la aplicación no cierre correctamente las conexiones a la base de datos, y configurar un max_connections alto puede provocar que su servidor no responda o tenga una carga alta. El uso de un grupo de conexiones en el nivel de la aplicación puede ayudar a resolver el problema aquí.

tamaño_caché_hilo

Este es el caché para evitar la creación excesiva de subprocesos. Cuando un cliente se desconecta, los subprocesos del cliente se colocan en el caché si hay menos subprocesos que thread_cache_size allí. Las solicitudes de subprocesos se satisfacen reutilizando los subprocesos tomados del caché si es posible, y solo cuando el caché está vacío se crea un nuevo subproceso. Esta variable se puede aumentar para mejorar el rendimiento si tiene muchas conexiones nuevas. Normalmente, esto no proporciona una mejora notable en el rendimiento si tiene una buena implementación de subprocesos. Sin embargo, si su servidor ve cientos de conexiones por segundo, normalmente debe configurar thread_cache_size lo suficientemente alto como para que la mayoría de las conexiones nuevas usen hilos almacenados en caché. Al examinar la diferencia entre las variables de estado Connections y Threads_created, puede ver qué tan eficiente es el caché de subprocesos. Usando la fórmula indicada en la documentación, 8 + (max_connections / 100) es lo suficientemente bueno.

tamaño_caché_consulta

Para algunas configuraciones, esta variable es su peor enemigo. Para algunos sistemas que experimentan una gran carga y están ocupados con muchas lecturas, esta variable lo atascará. Ha habido puntos de referencia que fueron bien probados, por ejemplo, Percona. Esta variable debe establecerse en 0 junto con query_cache_type =0 también para desactivarla. La buena noticia en MySQL 8.0 es que el equipo de MySQL ha dejado de admitir esto, ya que esta variable realmente puede causar problemas de rendimiento. Tengo que estar de acuerdo en su blog en que es poco probable que mejore la previsibilidad del rendimiento. Si está comprometido a usar el almacenamiento en caché de consultas, le sugiero que use Redis o ProxySQL.

Motor de almacenamiento - InnoDB

InnoDB es un motor de almacenamiento compatible con ACID con varias características para ofrecer junto con soporte de clave externa (integridad referencial declarativa). Esto tiene muchas cosas que decir aquí, pero ciertas variables a considerar para el ajuste:

innodb_buffer_pool_size

Esta variable actúa como un búfer clave de MyISAM pero tiene muchas cosas que ofrecer. Dado que InnoDB depende en gran medida del grupo de búfer, consideraría establecer este valor típicamente en 70%-80% de la memoria de su servidor. También es favorable que tenga un espacio de memoria más grande que su conjunto de datos y establezca un valor más alto para su grupo de búfer, pero no demasiado. En ClusterControl, esto se puede monitorear usando nuestros Paneles -> Métricas de InnoDB -> Gráfico de páginas de grupo de búfer de InnoDB. También puede monitorear esto con MOSTRAR ESTADO GLOBAL usando las variables Innodb_buffer_pool_pages*.

innodb_buffer_pool_instancias

Para su carga de trabajo de simultaneidad, establecer esta variable puede mejorar la simultaneidad y reducir la contención como diferentes subprocesos de lectura/escritura en páginas almacenadas en caché. Las instancias mínimas de innodb_buffer_pool_instances deben estar entre 1 (mínimo) y 64 (máximo). Cada página que se almacena o se lee del grupo de búferes se asigna a una de las instancias del grupo de búferes de forma aleatoria mediante una función hash. Cada grupo de búfer administra sus propias listas libres, listas de vaciado, LRU y todas las demás estructuras de datos conectadas a un grupo de búfer, y está protegido por su propio mutex de grupo de búfer. Tenga en cuenta que esta opción solo surte efecto cuando innodb_buffer_pool_size>=1GiB y su tamaño se divide entre las instancias del grupo de búfer.

innodb_log_file_size

Esta variable es el archivo de registro en un grupo de registro. El tamaño combinado de los archivos de registro (innodb_log_file_size * innodb_log_files_in_group) no puede superar un valor máximo ligeramente inferior a 512 GB. Según Vadim, un tamaño de archivo de registro más grande es mejor para el rendimiento, pero tiene un inconveniente (importante) del que debe preocuparse:el tiempo de recuperación después de un bloqueo. Debe equilibrar el tiempo de recuperación en el caso poco común de una recuperación de fallas versus maximizar el rendimiento durante las operaciones pico. ¡Esta limitación puede traducirse en un proceso de recuperación de fallas 20 veces más largo!

Para elaborarlo, un valor mayor sería bueno para los registros de transacciones de InnoDB y es crucial para un rendimiento de escritura bueno y estable. Cuanto mayor sea el valor, menos actividad de vaciado del punto de control se requiere en el grupo de búfer, lo que ahorra E/S del disco. Sin embargo, el proceso de recuperación es bastante lento una vez que su base de datos se cerró de manera anormal (bloqueo o eliminación, ya sea OOM o accidental). Idealmente, puede tener 1-2 GiB en producción pero, por supuesto, puede ajustar esto. La evaluación comparativa de estos cambios puede ser una gran ventaja para ver cómo funciona, especialmente después de un bloqueo.

innodb_log_buffer_size

Para guardar la E/S del disco, InnoDB escribe los datos de cambio en el búfer de registro de lt y usa el valor de innodb_log_buffer_size que tiene un valor predeterminado de 8MiB. Esto es beneficioso especialmente para transacciones grandes, ya que no necesita escribir el registro de cambios en el disco antes de confirmar la transacción. Si su tráfico de escritura es demasiado alto (inserciones, eliminaciones, actualizaciones), aumentar el tamaño del búfer ahorra E/S del disco.

innodb_flush_log_at_trx_commit

Cuando innodb_flush_log_at_trx_commit se establece en 1, el búfer de registro se vacía en cada confirmación de transacción en el archivo de registro en el disco y proporciona la máxima integridad de datos, pero también tiene un impacto en el rendimiento. Establecerlo en 2 significa que el búfer de registro se vacía en la memoria caché del archivo del sistema operativo en cada confirmación de transacción. La implicación de 2 es óptima y mejora el rendimiento si puede relajar sus requisitos de ACID y puede permitirse perder transacciones durante el último segundo o dos en caso de fallas del sistema operativo.

innodb_thread_concurrency

Con las mejoras en el motor InnoDB, se recomienda permitir que el motor controle la concurrencia manteniéndolo en el valor predeterminado (que es cero). Si ve problemas de simultaneidad, puede ajustar esta variable. Un valor recomendado es 2 veces la cantidad de CPU más la cantidad de discos. Su variable dinámica significa que puede establecerse sin reiniciar el servidor MySQL.

método_innodb_flush

Sin embargo, esta variable debe probarse y probarse en qué hardware se adapta mejor a usted. Si está utilizando un RAID con caché respaldado por batería, DIRECT_IO ayuda a aliviar la presión de E/S. La E/S directa no se almacena en caché, por lo que evita el almacenamiento en búfer doble con el grupo de búfer y la caché del sistema de archivos. Si su disco está almacenado en SAN, O_DSYNC podría ser más rápido para una carga de trabajo de lectura intensa con principalmente declaraciones SELECT.

innodb_file_per_table

innodb_file_per_table está activado de forma predeterminada desde MySQL 5.6. Por lo general, esto se recomienda, ya que evita tener un gran espacio de tabla compartido y le permite recuperar espacio cuando elimina o trunca una tabla. El tablespace separado también se beneficia del esquema de copia de seguridad parcial de Xtrabackup.

innodb_stats_on_metadata

Esto intenta mantener bajo control el porcentaje de páginas sucias, y antes del complemento Innodb, esta era realmente la única forma de ajustar el vaciado del búfer sucio. Sin embargo, he visto servidores con un 3 % de buffers sucios y están alcanzando su punto de control máximo. La forma en que esto aumenta el vaciado del búfer sucio tampoco escala bien en los subsistemas de alto nivel de E/S, simplemente duplica el vaciado del búfer sucio por segundo cuando el % de páginas sucias supera esta cantidad.

innodb_io_capacidad

Esta configuración, a pesar de todas nuestras grandes esperanzas de que permitiría a Innodb hacer un mejor uso de nuestro IO en todas las operaciones, simplemente controla la cantidad de descarga de páginas sucias por segundo (y otras tareas en segundo plano, como la lectura anticipada). Haz esto más grande, descargas más por segundo. Esto no se adapta, simplemente hace muchos iops cada segundo si hay búferes sucios para vaciar. Eliminará de manera efectiva cualquier optimización de la consolidación de IO si tiene una carga de trabajo de escritura lo suficientemente baja (es decir, las páginas sucias se eliminan casi de inmediato; en este caso, podríamos estar mejor sin un registro de transacciones). También puede privar rápidamente de lecturas y escrituras de datos en el registro de transacciones si establece un valor demasiado alto.

innodb_write_io_threads

Controla cuántos subprocesos tendrán escrituras en curso en el disco. No estoy seguro de por qué esto sigue siendo útil si puede usar AIO nativo de Linux. Estos también pueden volverse inútiles por los sistemas de archivos que no permiten la escritura paralela en el mismo archivo por más de un subproceso (particularmente si tiene relativamente pocas tablas y/o usa los espacios de tablas globales)

innodb_adaptive_flushing

Especifica si se ajusta dinámicamente la tasa de vaciado de páginas sucias en el grupo de búfer de InnoDB en función de la carga de trabajo. El ajuste dinámico de la tasa de descarga tiene por objeto evitar ráfagas de actividad de E/S. Por lo general, esto está habilitado de forma predeterminada. Esta variable, cuando está habilitada, intenta ser más inteligente a la hora de vaciar de forma más agresiva en función del número de páginas sucias y la tasa de crecimiento del registro de transacciones.

innodb_servidor_dedicado

Esta variable es nueva en MySQL 8.0 que se aplica globalmente y requiere un reinicio de MySQL ya que no es una variable dinámica. Sin embargo, como la documentación establece que se desea que esta variable esté habilitada solo si su MySQL se ejecuta en un servidor dedicado. De lo contrario, no habilite esto en un host compartido ni comparta los recursos del sistema con otras aplicaciones. Cuando esto está habilitado, InnoDB realizará una configuración automática para la cantidad de memoria detectada para las variables innodb_buffer_pool_size, innodb_log_file_size, innodb_flush_method. La única desventaja es que no puede tener la posibilidad de aplicar los valores deseados en las variables detectadas mencionadas.

Mi ISAM

tamaño_búfer_clave

InnoDB es el motor de almacenamiento predeterminado ahora de MySQL, el valor predeterminado para key_buffer_size probablemente se pueda reducir a menos que esté usando MyISAM productivamente como parte de su aplicación (pero, ¿quién usa MyISAM en producción ahora?). Sugeriría aquí configurar quizás el 1% de RAM o 256 MiB al inicio si tiene una memoria más grande y dedicar la memoria restante para la memoria caché del sistema operativo y el grupo de búfer de InnoDB.

Otras provisiones para el desempeño

slow_query_log

Por supuesto, esta variable no ayuda a impulsar su servidor MySQL. Sin embargo, esta variable puede ayudarlo a analizar consultas de rendimiento lento. El valor se puede establecer en 0 o en APAGADO para deshabilitar el registro. Configurándolo en 1 o en ON para habilitar esto. El valor predeterminado depende de si se proporciona la opción --slow_query_log. El destino de la salida del registro está controlado por la variable del sistema log_output; si ese valor es NINGUNO, no se escriben entradas de registro incluso si el registro está habilitado. Puede establecer el nombre de archivo o el destino del archivo de registro de consultas configurando la variable slow_query_log_file.

long_query_time

Si una consulta tarda más de estos segundos, el servidor incrementa la variable de estado Slow_queries. Si el registro de consultas lentas está habilitado, la consulta se registra en el archivo de registro de consultas lentas. Este valor se mide en tiempo real, no en el tiempo de la CPU, por lo que una consulta que está por debajo del umbral en un sistema poco cargado puede estar por encima del umbral en uno muy cargado. Los valores mínimo y predeterminado de long_query_time son 0 y 10, respectivamente. Tenga en cuenta también que si la variable min_examined_row_limit se establece en> 0, no registrará consultas aunque tarde demasiado si el número de filas devueltas es menor que el valor establecido en min_examined_row_limit.

Para obtener más información sobre cómo ajustar el registro lento de consultas, consulte la documentación aquí.

sincronizar_binlog

Esta variable controla la frecuencia con la que MySQL sincronizará los binlogs con el disco. De forma predeterminada (>=5.7.7), se establece en 1, lo que significa que se sincronizará con el disco antes de que se confirmen las transacciones. Sin embargo, esto impone un impacto negativo en el rendimiento debido a un mayor número de escrituras. Pero esta es la configuración más segura si desea cumplir estrictamente con ACID junto con sus esclavos. Alternativamente, puede establecer esto en 0 si desea deshabilitar la sincronización del disco y simplemente confiar en el sistema operativo para vaciar el registro binario en el disco de vez en cuando. Establecerlo en un valor superior a 1 significa que el binlog se sincroniza con el disco después de que se hayan recopilado N grupos de confirmación de registros binarios, donde N es> 1.

Volcar/Restaurar grupo de búfer

Es bastante común que su base de datos de producción necesite calentarse desde un inicio/reinicio en frío. Al volcar el grupo de búfer actual antes de reiniciar, guardaría el contenido del grupo de búfer y una vez que esté activo, cargará el contenido nuevamente en el grupo de búfer. Por lo tanto, esto evita la necesidad de calentar su base de datos de nuevo a el caché Tenga en cuenta que esta versión se introdujo en 5.6 pero Percona Server 5.5 ya la tiene disponible, en caso de que se lo pregunte. Para habilitar esta función, configure ambas variables innodb_buffer_pool_dump_at_shutdown =ON e innodb_buffer_pool_load_at_startup =ON.

Hardware

Ahora estamos en 2019, ha habido muchas mejoras de hardware nuevas. Por lo general, no existe un requisito estricto de que MySQL requiera un hardware específico, pero esto depende de lo que necesite que haga la base de datos. Espero que no estés leyendo este blog porque estás haciendo una prueba si se ejecuta en un Intel Pentium de 200 MHz.

Para la CPU, los procesadores más rápidos con múltiples núcleos serán óptimos para MySQL en las versiones más recientes al menos desde la 5.6. Los procesadores Xeon/Itanium de Intel pueden ser costosos, pero están probados para plataformas informáticas escalables y confiables. Amazon ha estado enviando sus instancias EC2 que se ejecutan en la arquitectura ARM. Aunque personalmente no he intentado ejecutar ni recuerdo haber ejecutado MySQL en la arquitectura ARM, hay puntos de referencia que se realizaron hace años. Las CPU modernas pueden escalar sus frecuencias hacia arriba y hacia abajo en función de la temperatura, la carga y las políticas de ahorro de energía del sistema operativo. Sin embargo, existe la posibilidad de que la configuración de su CPU en su sistema operativo Linux se establezca en un gobernador diferente. Puede comprobarlo o configurarlo con el regulador de "rendimiento" haciendo lo siguiente:

echo performance | sudo tee /sys/devices/system/cpu/cpu[0-9]*/cpufreq/scaling_governor

Para la memoria, es muy importante que su memoria sea grande y pueda equiparar el tamaño de su conjunto de datos. Asegúrese de tener swappiness =1. Puede comprobarlo comprobando sysctl o comprobando el archivo en procfs. Esto se logra haciendo lo siguiente:

$ sysctl -e vm.swappiness
vm.swappiness = 1

O establecerlo en un valor de 1 de la siguiente manera

$ sudo sysctl vm.swappiness=1
vm.swappiness = 1

Otra gran cosa a considerar para la administración de su memoria es considerar desactivar THP (Transparrent Huge Pages). En el pasado, recuerdo que tuvimos algunos problemas extraños con la utilización de la CPU y pensamos que se debía a la E/S del disco. Resultó que el problema estaba en el hilo del núcleo que asigna memoria dinámicamente durante el tiempo de ejecución. No solo esto, durante la desfragmentación del kernel, su memoria se asignará rápidamente a medida que la pasa a THP. La memoria estándar de HugePages se asigna previamente al inicio y no cambia durante el tiempo de ejecución. Puede verificar y deshabilitar esto haciendo lo siguiente:

$ cat /sys/kernel/mm/transparent_hugepage/enabled
$ echo "never" > /sys/kernel/mm/transparent_hugepage/enabled

Para Disk, es importante que tenga un buen rendimiento. El uso de RAID10 es la mejor configuración para una base de datos con una unidad de respaldo de batería. Con la llegada de las unidades flash que ofrecen un alto rendimiento de disco y E/S de disco alta para lectura/escritura, es importante que pueda administrar la utilización de disco alta y la E/S de disco.

Sistema operativo

La mayoría de los sistemas de producción que se ejecutan en MySQL se ejecutan en Linux. Es porque MySQL ha sido probado y evaluado en Linux, y parece que es el estándar de facto para una instalación de MySQL. Sin embargo, por supuesto, no hay nada que le impida usarlo en la plataforma Unix o Windows. Sería más fácil si su plataforma ha sido probada y hay una amplia comunidad para ayudar, en caso de que tenga algún problema. La mayoría de las configuraciones se ejecutan en los sistemas RHEL/Centos/Fedora y Debian/Ubuntu. En AWS, Amazon tiene su Amazon Linux, que veo que algunos también utilizan en producción.

Lo más importante a considerar con su configuración es que su sistema de archivos usa XFS o Ext4. Por supuesto, hay ventajas y desventajas entre estos dos sistemas de archivos, pero no entraré en detalles aquí. Algunos dicen que XFS supera a Ext4, pero también hay informes de que Ext4 supera a XFS. ZFS también está saliendo a la luz como un buen candidato para un sistema de archivos alternativo. Jervin Real (de Percona) tiene un gran recurso sobre esto, puede consultar esta presentación durante la conferencia ZFS.

Enlaces externos

https://developer.okta.com/blog/2015/05/22/tcmalloc

https://www.percona.com/blog/2012/07/05/impacto-de-los-asignadores-de-memoria-en-mysql-rendimiento/

https://www.percona.com/live/18/sessions/benchmark-noise-reduction-how-to-configure-your-machines-for-stable-results

https://zfs.datto.com/2018_slides/real.pdf

https://docs.oracle.com/en/database/oracle/oracle-database/12.2/ladbi/disabling-transparent-hugepages.html#GUID-02E9147D-D565-4AF8-B12A-8E6E9F74BEEA