Degradación del rendimiento de Firebird: pruebas, mitos y realidad
Alexey Kovyazin, 16 de mayo de 2014
Puede descargar este artículo en formato PDF.
Recientemente en IBSurgeon realizamos una serie de pruebas de rendimiento con Firebird 2.5.2. Firebird 2.5.2 es la versión más popular de la base de datos Firebird, y sus usuarios a menudo tienen preguntas relacionadas con el rendimiento de Firebird.
Una de las preocupaciones más importantes con respecto al rendimiento de la base de datos es su degradación. Muchos usuarios afirman que sus aplicaciones de base de datos tienen problemas de rendimiento al alcanzar cierto valor umbral: puede ser 3Gb, 5Gb, el tamaño de la RAM, 20Gb, etc. La afirmación más popular es “el tamaño de la base de datos es mayor que el tamaño de la RAM”: cuando el tamaño de la base de datos Firebird alcanza el tamaño de la RAM, se informa que se vuelve muy lenta… ¿Es cierto?
Decidimos realizar una serie de pruebas para comprobar si existe tal degradación del rendimiento relacionada con el crecimiento de la base de datos. Decidimos simular el crecimiento de la vida útil de la base de datos con la misma carga en el mismo hardware, y para ello ejecutamos 11 pruebas con bases de datos de tamaño entre 9Gb y 30Gb:
Figura 1. Tamaños de bases de datos para las pruebas
Hardware de prueba y configuración de Firebird
El hardware de prueba tenía las siguientes características clave:
CPU AMD-FX8350, RAM 16GB, RAID1 de software SATA 2x4Tb discos Seagate, Sistema Operativo Windows Server 2008R2 (2008R2 es de 64 bits).
Como puede ver, es una configuración de hardware de gama baja; se puede comprar por menos de USD 1000 en el momento (mayo de 2014), y puede considerarse como una configuración típica de nivel bajo - quizás, excepto los grandes discos SATA, pero según el informe del fabricante, la velocidad de los discos SATA de 1Tb y 4Tb es casi la misma.
Dado que el objetivo de la prueba era medir los cambios de rendimiento del sistema típico, hemos utilizado Firebird (64 bits) con arquitectura SuperServer, no Classic, para simular completamente la situación en una pequeña empresa - usan lo que se instaló originalmente durante años. Como sabe, SuperServer usa solo 1 núcleo de CPU, por lo que probablemente Classic o SuperClassic (que pueden usar todos los núcleos de CPU) podrían mostrar mejores resultados en términos de rendimiento, pero nuestro objetivo no era la optimización del rendimiento.
Sin embargo, hemos ajustado firebird.conf con los cambios obvios que recomendamos para todas las instalaciones de Firebird SuperServer: aumento de búferes de página a 10000 y espacio temporal para ordenación.
Todas las bases de datos de prueba se crearon con un tamaño de página de 16384, solo por consistencia.
Pruebas
Carga
Cada prueba contenía 2 pasos: carga y simulación de 20 terminales que realizan inserciones, actualizaciones y eliminaciones.
El paso de carga lo realiza una aplicación cargadora (load.exe), que inserta datos en varias tablas. Como puede ver en la figura 2, los datos se cargan con diferente velocidad; varía desde ~35Mb/seg hasta 1Mb/seg.
Figura 2. Velocidad de carga de la base de datos (gráfico rojo)
Esto está relacionado con el diseño de la aplicación cargadora, no con Firebird: el cargador inserta rápidamente el 70% de la base de datos y luego llena lentamente el resto de los datos, y se repite con bases de datos de todos los tamaños. Es importante para nosotros que el cargador realice las mismas operaciones, por lo que podemos usar su velocidad promedio para medir la velocidad de carga.
Es importante decir que el cargador solo inserta datos, y los índices se crean después de que la carga esté completa.
Veamos la tabla con los resultados del paso de carga para 11 bases de datos entre 9 y 30Gb:
| # | tamaño de base de datos, gb | tiempo de carga, seg | velocidad de carga SATA, Mb/seg |
|---|---|---|---|
| 1 | 9,04 | 2535 | 3,65166075 |
| 2 | 10,80 | 3197 | 3,45924304 |
| 3 | 13,00 | 4057 | 3,281242297 |
| 4 | 15,50 | 4698 | 3,378458919 |
| 5 | 17,30 | 5455 | 3,24751604 |
| 6 | 19,90 | 6037 | 3,375451383 |
| 7 | 21,60 | 6473 | 3,417024564 |
| 8 | 24,20 | 7539 | 3,287014193 |
| 9 | 26,00 | 7779 | 3,422547885 |
| 10 | 28,60 | 8851 | 3,308823862 |
| 11 | 30,30 | 9266 | 3,348499892 |
Figura 3. Tiempo y velocidad de carga
O, es mejor mostrarlo en el gráfico de la figura 4:
Figura 4. Resultados de la prueba: velocidad de carga.
Como puede ver, hay un gráfico bastante estable, y la velocidad promedio del proceso de carga varía alrededor de 3.3-3.4Mb/seg. Tampoco hay signos de disminución de la velocidad de carga cuando el tamaño de la base de datos supera el tamaño de la RAM (después de la base de datos #5, con tamaño 17.3Gb).
Rendimiento
Entonces, los tiempos de carga se ven bastante prometedores, ¿qué hay de los resultados reales de rendimiento?
Antes de ir a los resultados de rendimiento, revisemos rápidamente el proceso de simulación.
La simulación ejecuta 20 hilos, y cada uno de ellos ejecuta aleatoriamente varias operaciones de negocio: crear nuevo pedido, procesar pago, contar productos en stock, procesar entrega de pedido, etc. (para más detalles puede ver los textos SQL de los procedimientos almacenados reales). Como puede ver, este es el conjunto habitual de operaciones de negocio de una aplicación abstracta de inventario/ventas.
La aplicación de prueba mide el número de operaciones de negocio por segundo, e informa un número promedio. Por supuesto, este número es un parámetro artificial, pero es suficientemente bueno para la comparación.
Resultados de la prueba de rendimiento:
| # | tamaño de base de datos, gb | rendimiento en SATA |
|---|---|---|
| 1 | 9,04 | 494,73 |
| 2 | 10,80 | 491,94 |
| 3 | 13,00 | 480,36 |
| 4 | 15,50 | 469,11 |
| 5 | 17,30 | 446,42 |
| 6 | 19,90 | 431,61 |
| 7 | 21,60 | 426,85 |
| 8 | 24,20 | 424,5 |
| 9 | 26,00 | 414,04 |
| 10 | 28,60 | 409,14 |
| 11 | 30,30 | 407,97 |
Figura 5. Tabla con los resultados de la prueba de rendimiento.
O, es mejor ver los resultados en la representación gráfica:
Figura 6. Gráfico de resultados de rendimiento
Como puede ver, hay una degradación lenta del rendimiento con el crecimiento del tamaño de la base de datos - cuanto más grande es la base de datos, más lenta funcionará (en el mismo hardware). Tampoco hay una gran caída del rendimiento cuando el tamaño de la base de datos supera la RAM. El crecimiento de la base de datos de 9Gb a 30Gb conduce a aproximadamente un 20% de pérdida de rendimiento.
Las bases de datos Firebird de 30Gb están por todas partes ahora, y crecen y crecen con el tiempo. Sin embargo, ¿qué pasará con el rendimiento de la base de datos cuando sea aún más grande? ¡Nos referimos a - MÁS GRANDE! ¿Qué pasará con el rendimiento cuando la base de datos se vuelva REALMENTE GRANDE?
Mr.Big
Para responder a esta pregunta decidimos mirar al final de la tabla de pruebas y realizar una prueba con una base de datos de 1.7Tb (1813 Gb), en el mismo hardware, con la misma configuración.
Carga
Entonces, creamos tal base de datos:
Figura 7. Tamaño de la base de datos - ahora con base de datos de 1813 Gb
La carga tomó 566448 segundos - 157 horas, 6.55 días. Es mucho tiempo, pero la velocidad promedio de carga fue… ¡3.28Mb/seg!
| # | tamaño de base de datos, gb | tiempo de carga, seg | velocidad de carga SATA, Mb/seg |
|---|---|---|---|
| 12 | 1813,969025 | 566448 | 3,279214122 |
Figura 8. Tiempo y velocidad de carga para la base de datos Firebird de 1.7Tb
En el gráfico se ve muy bien: el último punto (#12). Entonces, Firebird muestra muy buenos resultados de sus algoritmos de inserción.
Figura 9. Velocidad de carga - el punto #12 es para la base de datos Firebird de 1.7Tb
Rendimiento de Mr.Big
Luego ejecutamos la misma prueba de rendimiento - la línea 12 es para la base de datos de 1.7Tb.
| # | tamaño de base de datos, gb | rendimiento en SATA |
|---|---|---|
| 1 | 9,04 | 494,73 |
| 2 | 10,80 | 491,94 |
| 3 | 13,00 | 480,36 |
| 4 | 15,50 | 469,11 |
| 5 | 17,30 | 446,42 |
| 6 | 19,90 | 431,61 |
| 7 | 21,60 | 426,85 |
| 8 | 24,20 | 424,5 |
| 9 | 26,00 | 414,04 |
| 10 | 28,60 | 409,14 |
| 11 | 30,30 | 407,97 |
| 12 | 1813,969025 | 169,33 |
Figura 10. Resultados de la prueba de rendimiento - la línea 12 es para la base de datos de 1.7Tb
Y en el gráfico:
Figura 11. Rendimiento, el punto #12 es para la base de datos de 1.7Tb
El resultado confirma que hay una degradación lenta y estable del rendimiento en Firebird - mientras 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).
No es una situación común que una base de datos (en el mismo hardware de gama baja) crezca de 30Gb a 1.7Tb, pero Firebird funcionará incluso en esta situación.
Base de datos grande en detalle
Para entender mejor la base de datos de 1.7Tb, recopilamos estadísticas de la base de datos para la base de datos Mr.Big y las analizamos en IBAnalyst:
Figura 12. Tablas de la base de datos de 1.7Tb en IBAnalyst
Como puede ver, hay 2 tablas grandes - ORDER_LINE (~600 Gb) con 6.3 mil millones de registros y STOCK (~680 Gb) con 2.1 mil millones de registros.
Y, para estas tablas hay 2 índices con profundidad = 4 - significa que cada solicitud hace 4 lecturas de páginas de índice antes de la lectura real de los datos. El índice ORDER_LINE_PK tiene un tamaño de 50Gb.
Figura 13. Índices de la base de datos Firebird de 1.7Tb
A pesar del enorme número de registros, las estadísticas de la base de datos se ven bien, por lo que no es sorprendente que Firebird muestre resultados bastante buenos incluso para una base de datos grande en hardware de gama baja.
Pruebas de Firebird con unidad SSD
Después de completar la serie de pruebas de Firebird en hardware de gama baja, decidimos comprobar cuáles serían los resultados en el otro extremo de la tecnología de almacenamiento de datos e instalamos una unidad SSD en el mismo servidor.
Instalamos la unidad SSD Plextor PX-256M M5 Pro, y ejecutamos la misma serie de pruebas (excepto la base de datos de 1.7Tb), con la misma configuración. Los resultados se agregaron a los gráficos con dispositivos SATA, véalos a continuación.
Carga
Como puede ver, el tiempo de carga en SSD es el mismo que en SATA. Este es un resultado esperado: la velocidad de las operaciones de escritura secuencial es casi la misma en unidades SATA y SSD.
Figura 14. Carga en SSD y SATA
Rendimiento
Vea los resultados de rendimiento:
Figura 15. Rendimiento en SSD y SATA
Como puede ver, el rendimiento con operaciones de IO aleatorias muestra resultados ~8x mejores para la unidad SSD. Sabíamos por nuestra experiencia con bases de datos de clientes que SSD es 30-50% más rápido con aplicaciones del mundo real, pero un aumento de 8x es muy alto.
Sin embargo, esta prueba es artificial y está especialmente diseñada para simular operaciones OLTP de alta carga, con muchas actualizaciones/eliminaciones, pero sin grandes recuperaciones. Una aplicación de base de datos habitual no funciona en este modo todo el tiempo. Esto explica por qué SSD muestra resultados tan altos en este caso particular.
Resumen
Entonces, ¿qué hemos aprendido de estas pruebas?
En primer lugar - el rendimiento de Firebird no tiene grandes disminuciones relacionadas con alguna restricción de tamaño. En el mismo hardware, el rendimiento disminuirá lentamente con el crecimiento del tamaño de la base de datos. Tal disminución del rendimiento puede compensarse con el ajuste de la configuración de Firebird o con una actualización inteligente del hardware.
Es un buen lugar para mencionar que IBSurgeon ofrece servicio de optimización del rendimiento de Firebird - utilizando datos experimentales que recopilamos de pruebas como esta, podemos aumentar significativamente el rendimiento de las bases de datos Firebird e InterBase.
Luego, supimos que incluso bases de datos Firebird muy grandes (1.7 terabytes) funcionarán en hardware de gama baja con una pérdida de rendimiento significativa, pero aceptable.
Y tercero, SSD es realmente bueno para aplicaciones OLTP. Probablemente sea la forma más económica de mejorar el rendimiento de la base de datos en este momento. Por supuesto, usar SSD no solucionará problemas con planes de consulta deficientes e índices ineficaces, pero puede aumentar el rendimiento en general.
Continuará: Más detalles sobre la base de datos Firebird de 1.7 Terabytes.