Desde que MySQL se bifurcó originalmente para formar MariaDB, ha sido ampliamente respaldado y adoptado rápidamente por una gran audiencia en la comunidad de bases de datos de código abierto. Originalmente un reemplazo directo, MariaDB ha comenzado a diferenciarse de MySQL, especialmente con el lanzamiento de MariaDB 10.2.
A pesar de esto, sin embargo, todavía no hay una diferencia reveladora real entre MariaDB y MySQL, ya que ambos tienen motores que son compatibles y pueden ejecutarse de forma nativa entre sí. Así que no se sorprenda si el ajuste de su configuración de MariaDB tiene un enfoque similar al ajuste de MySQL.
Este blog discutirá la puesta a punto de MariaDB, específicamente aquellos sistemas que se ejecutan en un entorno Linux.
Optimización de sistemas y hardware de MariaDB
MariaDB recomienda que mejore su hardware en el siguiente orden de prioridad...
Memoria
La memoria es el factor más importante para las bases de datos, ya que le permite ajustar las variables del sistema del servidor. Más memoria significa cachés de claves y tablas más grandes, que se almacenan en la memoria para que los discos puedan acceder, y posteriormente se reduce un orden de magnitud más lento.
Sin embargo, tenga en cuenta que simplemente agregar más memoria puede no resultar en mejoras drásticas si las variables del servidor no están configuradas para hacer uso de la memoria adicional disponible.
Usar más ranuras de RAM en la placa base aumenta la frecuencia del bus y habrá más latencia entre la RAM y la CPU. Esto significa que es preferible usar el tamaño de RAM más alto por ranura.
Discos
El acceso rápido al disco es fundamental, ya que, en última instancia, es donde residen los datos. La cifra clave es el tiempo de búsqueda del disco (una medida de qué tan rápido se puede mover el disco físico para acceder a los datos), así que elija discos con el menor tiempo de búsqueda posible. También puede agregar discos dedicados para archivos temporales y registros de transacciones.
Ethernet rápida
Con los requisitos apropiados para su ancho de banda de Internet, Ethernet rápido significa que puede tener una respuesta más rápida a las solicitudes de los clientes, el tiempo de respuesta de replicación para leer registros binarios en los esclavos, los tiempos de respuesta más rápidos también son muy importantes, especialmente en Galera basados en clústeres.
CPU
Aunque los cuellos de botella del hardware a menudo se encuentran en otra parte, los procesadores más rápidos permiten que los cálculos se realicen con mayor rapidez y los resultados se envían al cliente con mayor rapidez. Además de la velocidad del procesador, la velocidad del bus del procesador y el tamaño de la caché también son factores importantes a considerar.
Configuración del programador de E/S de disco
Los planificadores de E/S existen como una forma de optimizar las solicitudes de acceso al disco. Combina solicitudes de E/S en ubicaciones similares en el disco. Esto significa que la unidad de disco no necesita buscar con tanta frecuencia y mejora enormemente el tiempo de respuesta general y ahorra operaciones de disco. Los valores recomendados para el rendimiento de E/S son noop y fecha límite.
noop es útil para verificar si las decisiones de programación de E/S complejas de otros programadores no están causando regresiones en el rendimiento de E/S. En algunos casos, puede ser útil para dispositivos que programan E/S por sí mismos, como almacenamiento inteligente, o dispositivos que no dependen del movimiento mecánico, como SSD. Por lo general, el programador de E/S DEADLINE es una mejor opción para estos dispositivos, pero debido a la menor sobrecarga, NOOP puede producir un mejor rendimiento en ciertas cargas de trabajo.
Para fecha límite, es un planificador de E/S orientado a la latencia. Cada solicitud de E/S tiene una fecha límite asignada. Por lo general, las solicitudes se almacenan en colas (lectura y escritura) ordenadas por números de sector. El algoritmo DEADLINE mantiene dos colas adicionales (lectura y escritura) donde las solicitudes se ordenan por fecha límite. Siempre que no se haya agotado el tiempo de espera de ninguna solicitud, se utiliza la cola del "sector". Si se agotan los tiempos de espera, las solicitudes de la cola de "fecha límite" se atienden hasta que no haya más solicitudes caducadas. Generalmente, el algoritmo prefiere lecturas sobre escrituras.
Para dispositivos PCIe (unidades SSD NVMe), tienen sus propias colas internas grandes junto con un servicio rápido y no requieren ni se benefician de configurar un programador de E/S. Se recomienda no tener ningún parámetro de configuración de modo de programador explícito.
Puede comprobar la configuración de su programador con:
cat /sys/block/${DEVICE}/queue/schedulerPor ejemplo, debería verse así:
cat /sys/block/sda/queue/scheduler
[noop] deadline cfqPara hacerlo permanente, edite el archivo de configuración /etc/default/grub, busque la variable GRUB_CMDLINE_LINUX y agregue un elevador como se muestra a continuación:
GRUB_CMDLINE_LINUX="elevator=noop"Aumentar el límite de archivos abiertos
Para garantizar un buen rendimiento del servidor, la cantidad total de conexiones de clientes, archivos de bases de datos y archivos de registro no debe exceder el límite máximo de descriptores de archivos en el sistema operativo (ulimit -n). Los sistemas Linux limitan el número de descriptores de archivo que cualquier proceso puede abrir a 1024 por proceso. En los servidores de bases de datos activos (especialmente los de producción), puede alcanzar fácilmente el límite predeterminado del sistema.
Para aumentar esto, edite /etc/security/limits.conf y especifique o agregue lo siguiente:
mysql soft nofile 65535
mysql hard nofile 65535Esto requiere reiniciar el sistema. Posteriormente, puede confirmar ejecutando lo siguiente:
$ ulimit -Sn
65535
$ ulimit -Hn
65535Opcionalmente, puede configurar esto a través de mysqld_safe si está iniciando el proceso mysqld a través de mysqld_safe,
[mysqld_safe]
open_files_limit=4294967295o si está usando systemd,
sudo tee /etc/systemd/system/mariadb.service.d/limitnofile.conf <<EOF
[Service]
LimitNOFILE=infinity
EOF
sudo systemctl daemon-reloadConfiguración de Swappiness en Linux para MariaDB
Linux Swap juega un papel importante en los sistemas de bases de datos. Actúa como su rueda de repuesto en su vehículo, cuando las fugas de memoria desagradables interfieren con su trabajo, la máquina se ralentizará... pero en la mayoría de los casos aún se podrá utilizar para terminar la tarea asignada.
Para aplicar cambios a su capacidad de intercambio, simplemente ejecute,
sysctl -w vm.swappiness=1Esto ocurre dinámicamente, sin necesidad de reiniciar el servidor. Para hacerlo persistente, edite /etc/sysctl.conf y agregue la línea,
vm.swappiness=1Es bastante común configurar swappiness=0, pero desde el lanzamiento de nuevos kernels (es decir, kernels> 2.6.32-303), se han realizado cambios, por lo que debe configurar vm.swappiness=1.
Optimizaciones del sistema de archivos para MariaDB
Los sistemas de archivos más comunes utilizados en entornos Linux que ejecutan MariaDB son ext4 y XFS. También hay ciertas configuraciones disponibles para implementar una arquitectura usando ZFS y BRTFS (como se menciona en la documentación de MariaDB).
Además de esto, la mayoría de las configuraciones de bases de datos no necesitan registrar el tiempo de acceso al archivo. Es posible que desee deshabilitar esto cuando monte el volumen en el sistema. Para hacer esto, edite su archivo /etc/fstab. Por ejemplo, en un volumen llamado /dev/md2, así se ve:
/dev/md2 / ext4 defaults,noatime 0 0Creación de una instancia óptima de MariaDB
Almacenar datos en un volumen separado
Siempre es ideal separar los datos de su base de datos en un volumen separado. Este volumen es específicamente para esos tipos de volúmenes de almacenamiento rápido, como tarjetas SSD, NVMe o PCIe. Por ejemplo, si todo el volumen de su sistema falla, tendrá el volumen de su base de datos seguro y tendrá la seguridad de que no se verá afectado en caso de que falle su hardware de almacenamiento.
Ajuste MariaDB para utilizar la memoria de manera eficiente
innodb_buffer_pool_size
El valor principal para ajustar en un servidor de base de datos con tablas enteramente/principalmente XtraDB/InnoDB, se puede configurar hasta el 80 % de la memoria total en estos entornos. Si se establece en 2 GB o más, probablemente también querrá ajustar innodb_buffer_pool_instances. Puede configurar esto dinámicamente si está utilizando MariaDB> =versión 10.2.2. De lo contrario, requiere un reinicio del servidor.
tmp_memory_table_size/max_heap_table_size
Para tmp_memory_table_size (tmp_table_size), si está tratando con tablas temporales grandes, configurarlo más alto proporciona ganancias de rendimiento, ya que se almacenará en la memoria. Esto es común en consultas que usan mucho GROUP BY, UNION o subconsultas. Aunque si max_heap_table_size es menor, se aplicará el límite inferior. Si una tabla supera el límite, MariaDB la convierte en una tabla MyISAM o Aria. Puede ver si es necesario aumentar comparando las variables de estado Created_tmp_disk_tables y Created_tmp_tables para ver cuántas tablas temporales del total creado se necesitaron convertir a disco. A menudo, las consultas GROUP BY complejas son responsables de exceder el límite.
Mientras que max_heap_table_size, este es el tamaño máximo para las tablas MEMORY creadas por el usuario. El valor establecido en esta variable solo se aplica a las tablas recién creadas o recreadas y no a las existentes. El menor de max_heap_table_size y tmp_table_size también limita las tablas internas en memoria. Cuando se alcanza el tamaño máximo, cualquier otro intento de insertar datos recibirá un error de "tabla... está llena". Las tablas temporales creadas con CREATE TEMPORARY no se convertirán a Aria, como ocurre con las tablas temporales internas, pero también recibirán un error de tabla llena.
innodb_log_file_size
Las memorias grandes con procesamiento de alta velocidad y disco de E/S rápido no son nuevas y tienen un precio razonable como se recomienda. Si prefiere obtener más ganancias de rendimiento, especialmente durante el manejo de sus transacciones InnoDB, es razonable establecer la variable innodb_log_file_size en un valor mayor, como 5 Gib o incluso 10 GiB. El aumento significa que las transacciones más grandes pueden ejecutarse sin necesidad de realizar E/S de disco antes de confirmar.
join_buffer_size
En algunos casos, sus consultas tienden a carecer del uso de la indexación adecuada o simplemente, hay instancias en las que necesita que se ejecute esta consulta. No, a menos que se llame o invoque mucho desde la perspectiva del cliente, establecer esta variable es mejor a nivel de sesión. Auméntalo para obtener uniones completas más rápidas cuando no sea posible agregar índices, aunque ten en cuenta los problemas de memoria, ya que las uniones siempre asignarán el tamaño mínimo.
Establezca su max_allowed_packet
MariaDB tiene la misma naturaleza que MySQL cuando maneja paquetes. Divide los datos en paquetes y el cliente debe conocer el valor de la variable max_allowed_packet. El servidor tendrá un búfer para almacenar el cuerpo con un tamaño máximo correspondiente a este valor max_allowed_packet. Si el cliente envía más datos que max_allowed_packet size, el socket se cerrará. La directiva max_allowed_packet define el tamaño máximo de paquete que se puede enviar.
Establecer este valor demasiado bajo puede hacer que una consulta se detenga y cierre su conexión de cliente, lo que es bastante común para recibir errores como ER_NET_PACKET_TOO_LARGE o Lost connection to MySQL server durante la consulta. Idealmente, especialmente en la mayoría de las demandas de aplicaciones actuales, puede comenzar a configurar esto en 512 MiB. Si es un tipo de aplicación de baja demanda, simplemente use el valor predeterminado y configure esta variable solo a través de la sesión cuando sea necesario si los datos que se enviarán o recibirán son demasiado grandes que el valor predeterminado (16MiB desde MariaDB 10.2.4). En ciertas cargas de trabajo que exigen que se procesen paquetes grandes, debe ajustar su valor más alto de acuerdo con sus necesidades, especialmente cuando se trata de replicación. Si max_allowed_packet es demasiado pequeño en el esclavo, esto también hace que el esclavo detenga el subproceso de E/S.
Usando Threadpool
En algunos casos, es posible que este ajuste no sea necesario o recomendado para usted. Los grupos de subprocesos son más eficaces en situaciones en las que las consultas son relativamente cortas y la carga está limitada a la CPU (cargas de trabajo OLTP). Si la carga de trabajo no está vinculada a la CPU, es posible que desee limitar la cantidad de subprocesos para ahorrar memoria para los búferes de memoria de la base de datos.
Usar threadpool es una solución ideal, especialmente si su sistema está experimentando un cambio de contexto y está encontrando formas de reducir esto y mantener una cantidad menor de subprocesos que la cantidad de clientes. Sin embargo, este número tampoco debería ser demasiado bajo, ya que también queremos aprovechar al máximo las CPU disponibles. Por lo tanto, debería haber, idealmente, un solo subproceso activo para cada CPU en la máquina.
Puede configurar thread_pool_max_threads, thread_pool_min_threads para el número máximo y mínimo de subprocesos. A diferencia de MySQL, esto solo está presente en MariaDB.
Establezca la variable thread_handling que determina cómo el servidor maneja los hilos para las conexiones de los clientes. Además de los subprocesos para conexiones de clientes, esto también se aplica a ciertos subprocesos internos del servidor, como los subprocesos esclavos de Galera.
Ajuste la caché de su tabla + max_connections
Si enfrenta ocurrencias ocasionales en la lista de procesos sobre los estados de apertura y cierre de tablas, puede significar que necesita aumentar su caché de tablas. También puede monitorear esto a través del indicador del cliente mysql ejecutando SHOW GLOBAL STATUS LIKE 'Open%table%'; y monitorear las variables de estado.
Para max_connections, si su aplicación requiere muchas conexiones simultáneas, puede comenzar a configurarlo en 500.
Para table_open_cache, será el número total de sus tablas, pero es mejor que agregue más según el tipo de consultas que atienda, ya que las tablas temporales también se almacenarán en caché. Por ejemplo, si tiene 500 mesas, sería razonable comenzar con 1500.
Mientras su table_open_cache_instances, comience a configurarlo en 8. Esto puede mejorar la escalabilidad al reducir la contención entre sesiones, el 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.
Para InnoDB, table_definition_cache actúa como un límite suave para la cantidad de instancias de tablas abiertas en la memoria caché del diccionario de datos de InnoDB. El valor que se definirá establecerá el número de definiciones de tablas que se pueden almacenar en la memoria caché de definiciones. Si usa una gran cantidad de tablas, puede crear una memoria caché de definición de tabla grande para acelerar la apertura 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. El valor mínimo es 400. El valor predeterminado se basa en la siguiente fórmula, limitada a un límite de 2000:
MIN(400 + table_open_cache / 2, 2000)Si la cantidad de instancias de tablas abiertas supera la configuración de table_definition_cache, el mecanismo LRU comienza a marcar las instancias de tablas para su desalojo y finalmente las elimina de la memoria caché del diccionario de datos. 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. El número de instancias de tablas con metadatos almacenados en caché podría ser mayor que el límite definido por table_definition_cache, porque las instancias de tablas principales y secundarias con relaciones de clave externa no se colocan en la lista de LRU y no están sujetas a expulsión de la memoria.
A diferencia de table_open_cache, table_definition_cache no utiliza descriptores de archivo y es mucho más pequeño.
Tratar con la caché de consultas
Preferiblemente, recomendamos deshabilitar el caché de consultas en toda su configuración de MariaDB. Debe asegurarse de que query_cache_type=OFF y query_cache_size=0 para completar la desactivación de la caché de consultas. A diferencia de MySQL, MariaDB sigue siendo completamente compatible con el caché de consultas y no tiene planes de retirar su soporte para usar el caché de consultas. Hay algunas personas que afirman que la caché de consultas aún les brinda beneficios de rendimiento. Sin embargo, esta publicación de Percona La caché de consultas de MySQL:el peor enemigo o el mejor amigo revela que la caché de consultas, si está habilitada, genera una sobrecarga y muestra un mal rendimiento del servidor.
Si tiene la intención de utilizar el caché de consultas, asegúrese de monitorear su caché de consultas ejecutando SHOW GLOBAL STATUS LIKE 'Qcache%';. Qcache_inserts contiene el número de consultas agregadas al caché de consultas, Qcache_hits contiene el número de consultas que han utilizado el caché de consultas, mientras que Qcache_lowmem_prunes contiene el número de consultas que se eliminaron del caché debido a la falta de memoria. A su debido tiempo, el uso y la habilitación de la caché de consultas pueden fragmentarse. Un Qcache_free_blocks alto en relación con Qcache_total_blocks puede indicar fragmentación. Para desfragmentarlo, ejecute FLUSH QUERY CACHE. Esto desfragmentará la caché de consultas sin descartar ninguna consulta.
Supervise siempre sus servidores
Es muy importante que supervise correctamente sus nodos de MariaDB. Las herramientas de monitoreo comunes (como Nagios, Zabbix o PMM) están disponibles si tiende a preferir las herramientas gratuitas y de código abierto. Para herramientas corporativas y completas, le sugerimos que pruebe ClusterControl, ya que no solo brinda monitoreo, sino que también ofrece asesores de rendimiento, alertas y alarmas que lo ayudan a mejorar el rendimiento de su sistema y a mantenerse actualizado con el actual. tendencias a medida que interactúa con el equipo de soporte. El monitoreo de la base de datos con ClusterControl es gratuito y forma parte de Community Edition.
Conclusión
Ajustar su configuración de MariaDB es casi el mismo enfoque que MySQL, pero con algunas disparidades, ya que difiere en algunos de sus enfoques y versiones que admite. MariaDB es ahora una entidad diferente en el mundo de las bases de datos y se ha ganado rápidamente la confianza de la comunidad sin ningún FUD. Tienen sus propias razones por las que tiene que implementarse de esta manera, por lo que es muy importante que sepamos cómo ajustar esto y optimizar su(s) servidor(es) MariaDB.
