Optimización de una base de datos Firebird SQL de 1.7 Terabytes
Alexey Kovyazin, 14-julio-2014
Como recordará de nuestros artículos anteriores, hemos investigado mitos sobre la degradación del rendimiento de Firebird ( /es/articles/firebird-performance-degradation-tests-myths-and-truth/), donde creamos varias bases de datos de 9Gb a 30Gb, y también probamos una base de datos Firebird muy grande (1.7 terabytes) (/es/articles/more-details-about-1-7-terabyte-firebird-sql-database/).
Todas las pruebas se realizaron en el mismo hardware, que es una configuración de bajo presupuesto: CPU AMD-FX8350, RAM 16GB, RAID1 de software SATA 2x4Tb discos duros Seagate, sistema operativo Windows Server 2008R2 (2008R2 es de 64 bits), y con la misma configuración de Firebird: Firebird 2.5.2 de 64 bits, SuperServer, con buffers de página y TempCacheSize aumentados. Puede descargar este archivo de configuración SuperServer de forma gratuita desde esta ubicación: /es/optimized-firebird-configuration/
Como resultado, tuvimos la siguiente imagen del rendimiento de la base de datos:
Figura 1. Degradación del rendimiento de 9Gb a 30Gb, y 1,7Tb
El punto #11 es una marca de rendimiento para la base de datos de 30Gb y #12 para la base de datos de 1.7 Terabytes: el tamaño de la base de datos ha crecido 60 veces (de 30Gb a 1813Gb), la pérdida de rendimiento fue de 2.4 veces (de 407 a 169 puntos).
Entonces, la pregunta es: ¿podemos mejorar el rendimiento de Firebird en el mismo hardware con ajustes de configuración?
¡Y la respuesta es: sí!
Potenciando FirebirdSQL
Como recordará, en esta prueba ejecutamos 20 conexiones simultáneas que realizan INSERTs intensivos y, menos intensivos, UPDATEs.
Todos los SELECTs son cortos y bien definidos, con planes de ejecución SQL efectivos, por lo que esta es una aplicación OLTP (procesamiento de transacciones en línea) típica. Para tales aplicaciones, lo más crítico para el rendimiento es el procesamiento paralelo. Firebird SuperServer 2.5.2 no es adecuado para el procesamiento de múltiples hilos: utiliza efectivamente solo 1 núcleo por base de datos, y este hecho hace que SuperServer no sea una muy buena opción para aplicaciones OLTP.
Por lo tanto, necesitamos cambiar la arquitectura de Firebird a Classic o SuperClassic, que admiten procesamiento de múltiples hilos y utilizan múltiples núcleos de CPU (hay 8 núcleos en la CPU AMD-FX8350).
Luego, se necesita algún ajuste, ya que la configuración predeterminada de Firebird no es óptima para nuestro sistema de prueba.
Parámetros de ajuste en firebird.conf
Caché de páginas
Entonces, para mejorar el rendimiento OLTP decidimos probar las arquitecturas Classic y SuperClassic. Uno de los parámetros clave para Classic y SuperClassic es el número de buffers de página en la caché. A diferencia de SuperServer, Classic y SuperClassic asignan caché de páginas por conexión.
Para más detalles sobre las arquitecturas de Firebird en 2.5 puede revisar esta tabla en http://www.firebirdsql.org/file/fb25.architecture_comparison.pdf
Hay una fórmula fácil para calcular el uso de memoria de caché de páginas para diferentes arquitecturas de Firebird:
-
- SuperServer: caché de páginas única por base de datos. El tamaño predeterminado de caché de páginas es 2048 páginas, la recomendación mutua es 10000 buffers. En nuestro caso, la caché era 16k (tamaño de página) x 10000 ~= 160Mb. Es para todas las conexiones.
-
- Classic y SuperClassic: el motor asigna caché de páginas para cada conexión. El tamaño predeterminado es 75 páginas, por lo que 16Kb (tamaño de página) x 75 = ~= 1.17 Mb, para cada conexión.
Obviamente, el tamaño de la caché de páginas debe aumentarse, ya que 75 páginas por conexión es demasiado bajo. Mostraremos a continuación los resultados de varios valores diferentes para el tamaño de la caché de páginas.
LockHashSlots
Internamente, el motor de Firebird utiliza una tabla de bloqueos para solicitar y adquirir bloqueos para objetos internos dentro de la base de datos, y para Classic y SuperClassic existe el parámetro LockHashSlots (valor predeterminado 1009). Debe aumentarse bajo alta carga, para disminuir las cadenas hash en la tabla de bloqueos. Bueno, “alta carga” parece ser cualquier aplicación multiusuario del mundo real, por lo que lo hemos establecido en 30011 (para todas las pruebas).
LockMemSize
El parámetro LockMemSize se utiliza para configurar el tamaño inicial de la tabla de bloqueos (valor predeterminado 1048576). El motor puede aumentar el tamaño de la tabla según sea necesario. Sin embargo, el aumento de la tabla de bloqueos es costoso en términos de CPU y otros recursos, ya que se realiza mediante reasignación de memoria. Por lo tanto, lo hemos establecido en 7Mb, para ahorrar algo de tiempo y recursos de CPU.
Ejecuciones de prueba
Hicimos varias ejecuciones de prueba con varios valores de caché de páginas, con los siguientes resultados:
| Buffers de página | Classic, puntos de prueba | SuperClassic, puntos de prueba |
|---|---|---|
| 256 | 299 | 372 |
| 512 | 371 | 359 |
| 768 | 362 | 386 |
| 1024 | 312 | 387 |
| 1500 | 390 | 392 |
| 2048 | 285 | 284 |
Tabla 1. Ejecuciones de prueba para Classic y SuperClassic
Como puede ver, Classic y SuperClassic son mucho más efectivos que Firebird SuperServer para esta tarea: los resultados de las pruebas mejoraron de 169 puntos a 300-400, ¡esto está cerca de los resultados que tuvimos para la base de datos de 30Gb!
Es mejor ver los resultados en el siguiente gráfico:
Figura 2. Resultados de prueba para la base de datos de 1.7 Terabytes
Puede ver que el mejor rendimiento (tanto en Classic como en SuperClassic) fue con 1500 páginas por conexión, por lo que el tamaño de caché de páginas por conexión fue:
1500x16k ~= 23,4Mb
Con 2000 páginas por conexión, el rendimiento disminuyó significativamente. Parece que en algún lugar alrededor de 1500-2000 páginas, la ventaja del almacenamiento en caché se volvió menor que la sobrecarga causada por las interacciones de la tabla de bloqueos entre procesos para sincronizar páginas en las cachés de cada proceso del servidor. Obviamente, para un mayor número de conexiones esto ocurrirá antes, por lo que los servidores Classic/SuperClassic generalmente se configuran con números como 256-512 páginas.
También hay una caída en el rendimiento de Classic alrededor de 768-1000 cachés de páginas: no estamos seguros de por qué sucedió.
Resumen
Nuestros experimentos confirman que el rendimiento de Firebird puede aumentarse con la selección correcta de la arquitectura de Firebird (SuperServer, Classic o SuperClassic) y con un ajuste apropiado de varios parámetros importantes para la arquitectura específica.
Como resultado, una enorme base de datos Firebird SQL de 1.7 Tb puede funcionar en hardware de gama baja con un rendimiento suficientemente bueno. Como resultado práctico de estas pruebas, hemos creado varios archivos de configuración para todas las versiones de Firebird y todas las arquitecturas. Por supuesto, no están ajustados para la aplicación y/o hardware específicos, pero son mejores que los archivos de configuración predeterminados, que están hechos para una carga muy modesta.
Conjunto completo de archivos de configuración optimizados de Firebird: /es/optimized-firebird-configuration/
No dude en hacer cualquier pregunta: [email protected]
¿Qué sigue?
Estamos trabajando en una prueba integral que comparará el rendimiento de Firebird 2.5 y Firebird 3.0, con simulación de carga del mundo real y un gran número de conexiones. ¡Manténgase atento!