Optimizar MariaDB: varios consejos para tratar los picos de carga

¿Picos de carga? Te damos algunos consejos para optimizar MariaDB

Este año 2020 conviene ir en revisión de nuestro querido servidor de Pandora FMS y precisamente un componente muy importante es la base de datos (BD). Como ya saben nuestros consecuentes lectores (y si nos visitáis por primera vez podéis leer la introducción a la arquitectura en nuestra Wiki), MariaDB es una de las BD elegidas por Pandora FMS para guardar toda nuestra información acerca de nuestra monitorización de dispositivos: ¡Veamos cómo optimizar MariaDB!

Yo soy un debianita empedernido, es decir, gusto mucho de utilizar GNU/Debian, específicamente su distribución GNU/Ubuntu; pero para Pandora FMS se recomienda oficialmente a CentOS debido a la gran estabilidad de su desarrollo. Tranquilos, que aquí ya recibieron el primer consejo: instalar MariaDB sobre CentOS 7.

Nuestro segundo consejo, como introducción al tema de hoy, es la cantidad de dispositivos que debemos monitorizar. Para cien o más de ellos, aparte de recomendaros la Versión Enterprise de Pandora FMS, se debería utilizar un «Racimo de Bases de Datos en modo de Alta Disponibilidad», conocido en inglés como «High-Availability Database Cluster» o simplemente HA. El siguiente y corto vídeo introduce al tema; si queréis conocer más leed el artículo en nuestro blog dedicado al tema.

Ya sea que utilicemos un solo servidor, varios o muchos de ellos, siempre tendremos en cada instancia una BD manejada por MariaDB aguantando estoicamente los picos de carga.

¿Quién usa MariaDB?

Antes de optimizar MariaDB para recibir picos de carga veamos una breve historia… ¡es corta!

Wikipedia®, Google®, WordPress®, entre muchos otros utilizan MariaDB para tareas de misión crítica. ¿Veis que es corto el relato? No, ya va, que necesitáis saber algo más.

Esto a lo mejor ya lo conocéis: MariaDB es la bifurcación de MySQL® pero con licencia totalmente libre («GNU General Public License»). Su desarrollo y mantenimiento es llevado a cabo desde 2012 por la MariaDB Foundation («MariaDB»), y uno de sus clientes dorados es la MariaDB Corporation.

Leyenda: MariaDB Foundation https://mariadb.org/about/#logos-and-badges

Un cliente bronce de MariaDB es Percona…

Desde 2013, Google® paga directamente de su bolsillo a ingenieros para que trabajen en MariaDB. Otras empresas han hecho lo propio, o han donado millones de dólares estadounidenses a la fundación.

Michael Widenius es uno de los creadores de MySQL. «My» es el nombre, en finlandés, de su hija mayor… «Maria» es el nombre de la hija menor y el motor de almacenamiento que nació mucho antes que MariaDB; para diferenciarlo, lo renombraron luego a Aria. MyISAM es la contraparte de Aria.

Leyenda: Michael ”Monty” Widenius
https://commons.wikimedia.org/wiki/File:Michael_%E2%80%9DMonty%E2%80%9D_Widenius_at_MariaDB%E2%80%99s_Developers_Unconference_2019_in_New_York_City_04.jpg

Claro, por todo esto MySQL y MariaDB en la teoría y en la práctica son como hermanas, pero un momento, ¡hay diferencias importantes!

MariaDB, al momento de escribir estas líneas, se encuentra en la versión estable 10.3.21. Desde la versión 10.3.7 ha marcado distancia en lo que respecta al uso y desarrollo de InnoDB.

InnoDB a su vez reemplazó a MyISAM como motor de almacenamiento predeterminado para las tablas BD tanto en MySQL como en MariaDB.

Existen muchos motores de almacenamiento BD, incluso Facebook® tiene uno propio que explota al máximo el uso de discos duros de estado sólido; hay otro sumamente rápido que solo se almacena en memoria RAM y al apagar el equipo se borran todos los datos; otros tienen únicamente interés académico. Aquí hablaremos bastante de InnoDB.

Picos de carga

Un pico de carga, en computación, ocurre ya sea por nuestra interacción y/o hábitos humanos o por eventos imprevistos. El hecho mismo de que todos entremos a trabajar a las 9 de la mañana cada día crea un pico de carga para cualquier sistema informático, por ejemplo. Debemos aprender a vivir con los picos de carga, lidiar con ellos o al menos mitigarlos lo mejor posible. Veamos cómo optimizar MariaDB para ello.

Consejos

• • Número máximo de conexiones (“max_connections”): ciento cincuenta y uno trae prefijado; algunos recomiendan elevar a 750 o incluso 1000. Yo pienso que evidentemente debemos elevarlo pero sin perder de vista el hardware y/o recursos virtuales que tengamos asignados; por eso no coloco una cifra concreta. Límites: mínimo 10, máximo 100 mil).
  • Tamaño de de hilos (“thread_cache_size”): La función de estos hilos es mantener en memoria hasta por cinco minutos a fin de reutilizarlos, si es posible. Está relacionado con el punto anterior; el valor por defecto es 256; si elevamos aquel a más de 256 automáticamente, este se eleva al mismo valor. Pudiéramos primero probar el número máximo de conexiones en 256 como primer paso y evaluar el desempeño, aunque a ojo de buen cubero yo colocaría entre 150% a 200% el valor del número máximo de conexiones. Límites: mínimo 0, máximo 16384.
  • Batería de hilos (“Thread Pool”): lo nombro porque si lo activamos estropea el último consejo. Esta característica es útil si sabemos de antemano que las consultas serán muchas, de corta duración y que impliquen un trabajo extraordinario de cálculo del procesador. Si bien Pandora FMS hace uso intensivo de CPU para mantener a raya y a la mano los datos de los últimos 30 días, de resto lo que hace es recibir y guardar, por lo que considero que esta batería de hilos no goza de mayor utilidad en nuestro caso.
  • Registro binario de sincronización (“Sync Binlog”): esto daría para una entrada completa. Esencialmente significa sacrificar un poco de velocidad mandando al sistema operativo a escribir en disco luego de cada transacción; así prevenimos que se pierdan datos de sincronización a BD réplicas. Ya que el valor por defecto es cero (está en manos del sistema operativo), aumentando el valor a uno, que es el más lento, deberemos estar pendientes de aumentarlo si vemos que va muy lenta la cosa.
  • Optimización de InnoDB: como mencioné InnoDB es muy importante y MariaDB utiliza XtraDB, una versión mejorada de Percona para InnoDBD. A nivel de lenguaje de programación no veremos XtraDB, pues se identifica a sí mismo como InnoDB. Sí, todo un quebradero de cabeza. Sin embargo comparte características comunes, y el primer consejo de este grupo para optimizar MariaDB es modificar el tamaño del fondo de reserva («InnoDB Buffer Pool Size«). De nuevo depende de nuestro hardware o recursos virtualizados, pero siempre es bueno colocar hasta un máximo del 80% de la memoria, siempre y cuando no tengamos otro software corriendo en el mismo servidor y todas nuestras tablas sean InnoDB. Límites: mínimo 5 megabytes, por defecto 128 megabytes, si asignamos más de 2 gigabytes deberemos aumentar el número de instancias (vamos, dividir el fondo en unidades lógicas), máximo 8192 … ¡petabytes!
  • Tamaño del archivo de registro de InnoDB (“InnoDB Log File Size”): dependiendo del valor que establezcamos al fondo de reserva, deberemos asignar la mitad o menos. Este archivo de registro, al colocarlo de mayor tamaño, se reduce la escritura a costa de aumentar el tiempo de recuperación si se produce un fallo (corte de fuente eléctrica, por poner lo más común, o que alguien apague el servidor manualmente). Límites: mínimo 1 megabyte, por defecto 48 megabytes, máximo 512 gigabytes.
  • Tamaño del espacio temporal de registro InnoDB (“InnoDB Log Buffer Size”): aquí recomiendo una cifra, 64 megabytes, lo que reduce las escrituras y lecturas al disco. Límites: mínimo 256 kilobytes, por defecto 16 megabytes, máximo 4096 megabytes.
  • Intervalo de descarga del espacio temporal de registro (“InnoDB Log Flush Interval”): aquí no hay nada que cambiar, su valor por defecto es uno. Pero si gozamos de una redundancia y confiabilidad de suministro eléctrico, podemos cambiarlo a dos para aumentar el desempeño. Repito, ¡confiados siempre de que el Sistema de alimentación ininterrumpida (SAI) no nos defraude!
  • Capacidad de entrada y salida de InnodB («InnoDB IO Capacity«): este último consejo es mejor describirlo con el hardware de almacenamiento que tengamos, aunque es una aproximación porque en realidad debemos hacer pruebas especializadas en cada equipo en particular. Se mide en operaciones por segundo («IOPS«) y tiene un valor por defecto de 200 unidades, valor apto para discos duros de 10.000 RPM. La debemos bajar a 100 (cien) para discos menores a 7200 RPM. ¡Con discos duros de estado sólido la podemos llevar a 1000 (mil IOPS)!

Antes de despedirnos, recuerda que Pandora FMS es un software de monitorización flexible, capaz de monitorizar dispositivos, infraestructuras, aplicaciones, servicios y procesos de negocio.

¿Quieres conocer mejor qué es lo que Pandora FMS puede ofrecerte? Descúbrelo entrando aquí.

Si tienes que monitorizar más de 100 dispositivos también puedes disfrutar de una DEMO GRATUITA de 30 días de Pandora FMS Enterprise. Consíguela aquí.

Por último, recuerda que si cuentas con un número reducido de dispositivos para monitorizar puedes utilizar la versión OpenSource de Pandora FMS. Encuentra más información aquí.

No dudes en enviar tus consultas. ¡El equipo de Pandora FMS estará encantado de atenderte!