Contactos
IBSurgeon
Esta página fue traducida automáticamente. Lee el original en inglés. English

Biblioteca de IBSurgeon

23 formas más de acelerar Firebird

Alexey Kovyazin, IBSurgeon, [email protected], 08-Ene-2019

Traducciones: Portugués

¿Por qué “23 más”?

Algunos de ustedes recuerdan el artículo « 45 formas de acelerar Firebird», que fue publicado en mayo de 2016. Ahora es el momento de publicar la siguiente serie de consejos y trucos, basados principalmente en la experiencia de optimización y mantenimiento de bases de datos y servidores Firebird con un alto número de conexiones (1000+).

1. Configure las Opciones de Energía en Alto Rendimiento en Windows Server 2016 y 2019

Por defecto, Windows Server tiene un plan de energía configurado en “Equilibrado”, que no es adecuado para servidores de bases de datos. Configúrelo en “Alto rendimiento” y obtenga aproximadamente +20% de rendimiento para operaciones intensivas en CPU. Se puede configurar en línea, sin reinicio ni reinicio del sistema. La imagen a continuación muestra el gráfico de CPU, que demuestra la ventaja del plan de energía “Alto rendimiento”:

Más detalles sobre nuestras pruebas con planes de energía de Windows se pueden encontrar aquí.

2. Habilite «Interactuar con el escritorio» en Classic para Windows

Si está utilizando Firebird con arquitectura Classic en Windows, habilite la marca «Permitir que el servicio interactúe con el escritorio». Sin esta configuración, el recurso «montón de escritorio» está limitado por Windows, y Firebird no puede abrir más de 250-300 conexiones (depende de los metadatos de la base de datos y el consumo de memoria relacionado) - aparecerá un error de falta de memoria.

3. Cuidado: Controlador de Dominio

El problema de que Windows con el rol de Controlador de Dominio deshabilita la caché de escritura en el disco con la base de datos de Active Directory.

Esto afecta a Firebird de varias maneras (así como a otras aplicaciones, por supuesto), y demuestra un rendimiento significativamente peor que en los servidores sin roles de Active Directory.

Tenga en cuenta que este problema afecta a versiones populares de Windows como Windows Small Business Server 2011, así como a otras versiones con DC.

4. Aumente el límite de «archivos abiertos máximos» en Linux

Si está utilizando Linux como servidor de bases de datos, no olvide ajustar los límites para Firebird. Verifique los límites de su proceso Firebird (SuperServer o SuperClassic) con el siguiente comando:

Code 
cat /proc//limits

y preste atención a la línea con el número máximo de archivos abiertos.

Firebird puede usar hasta 4 manejadores por conexión, y si tiene algo como esto:

Code 
Max open files 4096 4096 files

significa que el número total de conexiones atendidas por el proceso Firebird estará limitado a alrededor de 1000.

Tenga en cuenta: si tiene 4 bases de datos en el servidor, la conexión para cada base de datos se cuenta.

Configure más - recomiendo 65535.

No olvide verificar nuevamente después de reiniciar el proceso Firebird: si se aplicó o no.

Para la arquitectura Classic, es necesario verificar y aumentar los límites para el usuario «firebird».

5. Use Linux moderno

Sí, entiendo que este consejo es trivial, pero he visto muchas veces una buena mejora de rendimiento después de la migración de CentOS 6 a 7, Ubuntu 12 a 16 (¡en el mismo hardware!), por lo que ahora es una recomendación imprescindible para servidores de bases de datos con más de 250-300 conexiones. El Linux moderno es un requisito previo antes de pasos de optimización adicionales.

Versiones recomendadas de Linux: CentOS 7.x y Ubuntu 16, 18.

6. Reserve el 40% de RAM para la caché de archivos en Windows

El Administrador de Memoria del SO tiene implicaciones con respecto a la asignación de memoria y, por defecto, Windows requiere el 40% de RAM para la caché de archivos.

Desafortunadamente, la pobre herramienta Administrador de tareas de Windows muestra la memoria utilizada para la caché de archivos como «libre», y algunos administradores intentan hacer que Firebird consuma toda esta memoria libre, por lo que configuran el parámetro DefaultDBCachePage en firebird.conf a valores muy altos, y esto generalmente conduce a intercambio (swapping).

Use siempre la herramienta RAMMap para ver el uso real de memoria en Windows.

La regla empírica para Windows Server (dedicado para uso como servidor Firebird) es la siguiente: la memoria de Firebird (Conjunto de trabajo) debe ser inferior al 40% de la RAM total. Si el tamaño total de los conjuntos de trabajo de todos los procesos es superior al 50%, Windows puede iniciar el intercambio.

Tenga en cuenta: “reservar” aquí significa no solo “no configurar demasiados búferes de página en Firebird” sino también, importante, restringir el uso de memoria de otro software. Por ejemplo, si tiene MS Exchange o MSSQL en el mismo servidor con Firebird, asegúrese de restringir sus apetitos de memoria.

Si está interesado en conocer los detalles, he grabado el seminario web dedicado a la gestión de memoria en Firebird:

7. Reserve el 30% de RAM para la caché de archivos en Linux

Linux trabaja con la caché de archivos de otra manera que Windows y, en general, la cantidad de RAM utilizada para la caché de archivos puede ser significativamente menor que en Windows, sin degradación notable del rendimiento de Firebird. Sin embargo, para garantizar un alto rendimiento del sistema con un alto número de conexiones, especialmente en Classic y SuperClassic, una buena idea será reservar el 30% de RAM para la caché de archivos.

8. Use irqbalance en Linux

irqbalance a menudo mejora el rendimiento de Firebird y el equilibrio de carga de CPU en servidores con un alto número de núcleos.

9. Para Máquinas Virtuales - tenga cuidado con la sobreasignación de memoria

Una Máquina Virtual puede configurarse para tener más memoria de la que existe físicamente en el host - con una característica conocida como sobreasignación de memoria (el nombre puede ser diferente en los diferentes sistemas de virtualización). Esto significa que en caso de un pico de consumo de memoria (en la VM con el servidor de bases de datos o en la VM vecina) puede comenzar el intercambio, lo que provocará retrasos significativos. Para una VM de alto rendimiento destinada a un servidor de bases de datos, toda la memoria debe ser estática.

10. Para Máquinas Virtuales - verifique los límites de la VM

A menudo las VM se crean con límites predeterminados de CPU y E/S, que pueden ser muy bajos, como 50 IOPS y 10% de CPU. Verifique la configuración de su VM de servidor y elimine cualquier límite - un servidor de bases de datos de alto rendimiento debe tener toda la CPU, ancho de banda y E/S posibles.

11. Limpie los archivos temporales de Firebird

Firebird crea muchos archivos temporales para varias operaciones: clasificación, procesamiento de BLOB, seguimiento. Estos archivos se almacenan en las siguientes ubicaciones: en Windows C:\ProgramData\firebird, en Linux / tmp / firebird

Normalmente estos archivos deben limpiarse automáticamente, sin embargo, a veces no sucede (por ejemplo, en caso de reinicio del servidor).

Verifique estas carpetas periódicamente y limpie los archivos antiguos - podría haber muchos GB de archivos obsoletos fb_NNN, y limpiarlos liberará espacio en la unidad del sistema.

12. No olvide habilitar la caché de archivos con una caché grande de Firebird

Como sabe, la caché de Firebird (también llamada «búferes de página») se especifica mediante el parámetro DefaultDBCachePages en firebird.conf/databases.conf, o directamente en el encabezado de la base de datos.

En Firebird 3 SuperServer, el tamaño de esta caché puede configurarse muy alto, pero es importante recordar otro parámetro: FileSystemCacheThreshold.

Si FileSystemCacheThreshold es menor que DefaultDBCachePages o los búferes de página, la caché de archivos del sistema operativo no se utilizará, lo que puede provocar problemas de rendimiento.

En el 99% de los casos, es mejor tener la caché de archivos habilitada.

Para garantizar esto, configure siempre los parámetros según la siguiente regla:

  • DefaultDBCachePages = X
  • FileSystemCacheThreshold = X+ N, N>1

Hay casos raros en los que deshabilitar la caché de archivos mejora el rendimiento - si tiene un ejemplo así, ¡contácteme - [email protected]!

13. Acelere la base de datos de seguridad

Cada conexión a la base de datos Firebird establece la conexión a la base de datos de seguridad (security3.fdb en caso de Firebird 3), y realiza varias lecturas y escrituras (páginas de transacción, página de encabezado). Si tiene conexiones frecuentes, el rendimiento de su base de datos de seguridad puede convertirse en un problema.

Como mínimo, puede hacer lo siguiente:

  • Aumente los búferes de página para securityN.fdb (el óptimo empírico es 256 búferes)
  • Mueva security3.fdb a una unidad rápida (es una característica estándar en Firebird 3, en 2.5 requerirá reinstalación)

Luego, puede configurar Forced Writes OFF para la base de datos de seguridad - la pequeña posibilidad de corrupción no es un problema en este caso.

La forma más radical es hacer que la base de datos de seguridad sea de solo lectura - eliminará todas las escrituras en ella.

Si no cambia a menudo los usuarios en la base de datos de seguridad, es la mejor solución.

14. Pruebe SuperClassic en Firebird 3

En Firebird 3, la arquitectura SuperServer fue fuertemente promocionada como la solución de rendimiento definitiva, pero hay algunos tipos de carga que demuestran mejor rendimiento con SuperClassic (pero no Classic - siempre funciona más lento que SuperServer/SuperClassic).

¿Cómo llevar a cabo este experimento de manera segura? Siga los pasos a continuación:

Para probar SuperClassic

  1. Configure en firebird.conf
  2. ServerMode=SuperClassic
  3. DefaultDbCachePages=1024
  4. gfix -buff 0
  5. Reinicie Firebird

Para volver a SuperServer

  1. Configure en firebird.conf
  2. ServerMode=SuperServer
  3. DefaultDbCachePages=N # N*tamaño de página*número_de_bases_de_datos < 25% RAM
  4. FileSystemCacheThreshold = N+1
  5. gfix -buff 0
  6. Reinicie Firebird

Por favor, escríbame ([email protected]) sobre los resultados del experimento, estoy interesado en ver los resultados.

15. ¿Base de datos grande? Aumente el tamaño de página

Por defecto, las bases de datos Firebird tienen los siguientes tamaños de página:

  • 2.5 - 4096 bytes
  • 3.0 - 8192 bytes

Sin embargo, el tamaño máximo de página es 16K (en 4.0 - 32K).

Para bases de datos de más de 100Gb, en el 95% de los casos, es mejor tener el tamaño de página más alto disponible, para:

  • Disminuir la profundidad de los índices. Se recomienda tener índices con profundidad menor o igual a 3. Los índices con profundidad 4 y 5 serán mucho más lentos
  • Aumentar la utilización de RAM. La caché de Firebird se especifica en páginas, 1000 páginas con tamaño de página de 8K serán 8Mb de memoria real, y con 16K - 16Mb.
  • Disminuir el número de páginas del sistema. Acelerará el acceso a los registros de las tablas grandes (menos saltos puntero-puntero-página de datos), y ayuda con la preparación de consultas SQL grandes. Para aumentar el tamaño de página de la base de datos, la base de datos debe respaldarse con la herramienta gbak y luego restaurarse con el parámetro -page ( gbak -c -page 16384).

Tenga en cuenta: si tiene una base de datos con muchos blobs pequeños, aumentar el tamaño de página puede disminuir la fragmentación o aumentarla, y es difícil predecir si aumentará o disminuirá el rendimiento.

16. No use el indicador no_reserve

El indicador no_reserve hace que Firebird no reserve espacio libre (30%) en las páginas de datos para las posibles versiones de registros, que ocurren después de UPDATE o DELETE. Este indicador permite que los datos se almacenen de manera más compacta (y el tamaño de la base de datos también es menor), pero en caso de UPDATE/DELETE todos los cambios van a la nueva página de datos. Como resultado, en la base de datos con el indicador no_reserve, las operaciones UPDATE/DELETE son más lentas.

Entonces, si su base de datos no es de solo lectura, recomiendo eliminar el indicador no_reserve.

Cómo verificar si está configurado o no - vea la línea Attributes en la salida de

Code 
gstat -h database

Cómo deshabilitarlo:

Code 
gfix -use reserve database

Después de este comando, las nuevas páginas de datos se crearán con espacio reservado.

Sin embargo, para lograr el efecto completo, es necesario respaldar la base de datos con gbak y luego restaurarla, en este caso, todas las páginas de datos tendrán espacio reservado.

Tenga en cuenta: el tamaño de la base de datos crecerá después de eliminar el indicador no_reserve y el respaldo/restauración.

17. Configure un tamaño inicial alto para la tabla de bloqueos de Firebird

La tabla de bloqueos es el mecanismo de Firebird que se utiliza para sincronizar el acceso a los objetos internos del motor.

La tabla de bloqueos de Firebird puede crecer automáticamente, pero su aumento es una operación lenta, que puede provocar micro-congelaciones. La tabla de bloqueos solo puede crecer, comenzando desde el tamaño inicial (se establece en firebird.conf).

Para evitar múltiples rondas de aumento de la tabla de bloqueos, una buena idea será vigilar el tamaño de la tabla de bloqueos al final del período de trabajo (día, semana, etc.), y luego establecerlo como el tamaño inicial en firebird.conf.

LockMemSize=99999999

Para su referencia: LockMemSize en sistemas de alta carga con ~1000 usuarios suele estar por debajo de 200Mb.

18. Usar fb_lock_print para contar el número de conexiones a la base de datos

Obtener el número de conexiones a la base de datos es una tarea frecuente para los desarrolladores de bases de datos: puede ser necesario para fines de licenciamiento, por ejemplo.

A menudo los desarrolladores usan la consulta SELECT count(*) FROM MON$ATTACHMENTS para obtener este valor, pero no es la forma óptima: las consultas frecuentes a las tablas MON$ pueden ser una carga para la base de datos, así que es mejor usar la alternativa:

Ejecute

fb_lock_print -d nombre_de_base_de_datos | alias

y verifique el valor de Owners: mostrará el número actual de conexiones a la base de datos.

19. Evitar LEFT JOINs innecesarios

A menudo veo consultas con una construcción como esta:

T1 LEFT JOIN T2 ON (…) WHERE T2.Field_condition

Esencialmente, la condición sobre T2 excluye los NULL del resultado de LEFT JOIN T2, por lo que es posible cambiar LEFT JOIN a INNER JOIN: no afectará el resultado de la consulta.

INNER JOIN da más libertad al optimizador de Firebird, y en las versiones modernas de Firebird, se optimiza mucho mejor que LEFT.

Especialmente tiene sentido en los siguientes casos:

  • Sin condición para T1 en la cláusula WHERE
  • T2 es una tabla pequeña

20. Evitar el conteo innecesario de registros

Otro error común en consultas complejas de bases de datos y procedimientos almacenados es usar select count() solo para verificar la existencia del registro.

La siguiente consulta leerá todos los registros según la condición1:

Code 
(select count(*)…. where condition11) >0

Mejor use esta construcción en su lugar:

Code 
Exists(select first 1 id where condition1)

Si la condición1 devuelve más de 1 registro, la opción propuesta será mucho más rápida, porque no lee todos los registros, se detiene después del primer registro obtenido.

21. Evitar ordenamientos innecesarios en procedimientos almacenados

El ordenamiento de los resultados de la consulta dentro del procedimiento almacenado debe estar justificado por la lógica de negocio.

Por ejemplo, en el ejemplo del procedimiento almacenado a continuación, la cláusula ORDER BY es inútil desde el punto de vista de la lógica de negocio, pero añade una operación de ordenamiento innecesaria.

Code 
create or alter procedure NEW_PROCEDURE
returns (
    SUMX double precision)
as
declare variable _amount double precision;
begin
for select T1.amount from Table1 t1 where ....
    order by id
    into :_amount
    do
    begin
     sumx=sumx+_amount
    end;
  suspend;
end

Revise su código PSQL para situaciones similares y elimine ORDER BY innecesarios (así como distinct y UNION).

22. No mantener consultas en estado preparado sin necesidad

A menudo vemos 500-1000 sentencias preparadas en cada conexión (se puede verificar con consultas MON$).

La gran mayoría de ellas se ejecuta solo una vez, y luego simplemente permanecen en la RAM, haciendo que el conjunto de trabajo de Firebird sea más grande y ralentizando las consultas MON$.

La recomendación es mantener las consultas SQL en estado preparado solo si se pretende ejecutarlas muchas veces, o si su tiempo de preparación es grande (puede ser así para consultas muy grandes con muchos joins y acceso a tablas enormes).

23. Siempre cerrar consultas con ordenamiento grande

Hasta que la consulta SQL con ordenamiento (ORDER BY, GROUP BY, UNION, distinct) no se cierre, Firebird retiene los registros ordenados en la memoria. El tamaño de la memoria asignada para el ordenamiento se establece con el parámetro TempCacheLimit en firebird.conf, por defecto es 64Mb.

Incluso con TempCacheLimit aumentado, las consultas de larga duración con un gran número de registros ordenados consumirán eventualmente toda la cantidad asignada, y como resultado, el ordenamiento irá a archivos temporales (es decir, disco). Como resultado, puede llevar a una lentitud significativa.

La recomendación es cerrar todas estas consultas de manera oportuna.

¿Preguntas?

No dude en contactarme con cualquier pregunta: [email protected]!