Firebird es un DBMS abierto muy popular en Rusia, y a pesar de la ausencia de campañas de marketing ruidosas, se usa en una gran cantidad de sistemas críticos, especialmente en sistemas médicos y de automatización del estado.
El tamaño de la base de datos y el número de usuarios activos en dichos sistemas suelen ser bastante grandes, por lo que en este artículo hablaré sobre la experiencia de optimizar la configuración de Firebird y Linux en base a ejemplos específicos de grandes bases de datos Firebird en
BeZdorov (Ingosstrakh),
AlfaZdrav , y me
referiré a la experiencia de otras empresas de optimización Firebird + Linux.
Echemos un vistazo más de cerca al tema de la optimización: Firebird 3.0.5 DBMS (con extensiones HQbird), sirve una base de datos de 691GB (actualmente) con 1000-1100 usuarios diarios, se ejecuta en Linux CentOS 7, el servidor usa una plancha HP DL380. La replicación en el servidor de respaldo está configurada para la base de datos (la cuestión de la replicación está fuera del alcance de este artículo).
El DBMS sirve al sistema de información médica Infoklinika (producido por la compañía rusa
Smart Delta Systems ), que es uno de los sistemas de información médica más populares en Rusia.
Echemos un vistazo a los detalles (las capturas de pantalla se toman de HQbird más adelante) del funcionamiento de esta base de datos:
Los datos se insertan intensamente en la base de datos, una ganancia diaria de aproximadamente 0.4 - 0.5 GB
1000-1100 conexiones es la carga diaria habitual:
A pesar del intenso crecimiento y el trabajo activo, la base de datos no contiene una cantidad significativa de versiones basura de registros, tanto gracias a las aplicaciones escritas con un buen conocimiento de la arquitectura de múltiples versiones, como debido a la recolección de basura configurada correctamente:
Marcadores de transacciones en la zona verde:
Por cierto, tenga en cuenta que los datos en la base de datos son cadenas, los blobs están presentes, pero hay pocos, solo 10 GB de 690 GB del tamaño total.
La naturaleza de la carga de la base de datos es mixta, el 75% de las operaciones de lectura y el 25% de la escritura:
Hierro
El servidor que sirve a este sistema no es malo, pero está lejos de ser de gama alta:
HP ProLiant DL380p Gen8, Gen8 2x Xeon(R) CPU E5v2 @ 2.60GHz, 24 logical cores with HT 320Gb RAM, 4 network cards
El subsistema de disco consta de dos partes: un disco local de 745 Gb y una conexión dual de 2 canales de fibra a la SAN, con una partición de 1.8Tb.
Sistema operativo
Usando CentOS 7, versión del kernel:
Linux version 3.10.0-957.21.3.el7.x86_64 (mockbuild@kbuilder.bsys.centos.org) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC) ) #1 SMP Tue Jun 18 16:35:19 UTC 2019
Para la pregunta lógica, por qué no se utilizan el núcleo más moderno y CentOS 8, la respuesta también es lógica: la migración de sistemas críticos se produce solo después del lanzamiento de varias versiones menores y pruebas rigurosas; este es uno de esos casos en que un error conocido es mejor que dos incógnitas.
Sin embargo, debe tenerse en cuenta que hasta 2017 el sistema funcionaba en CentOS 6.x, y después de la migración, se observó una mejora significativa en los indicadores de rendimiento.
Configuración de Linux
Una personalización de Linux absolutamente esencial para Firebird
Hay 2 parámetros que deben aumentarse en todos los servidores Linux donde se ejecuta Firebird: la cantidad de áreas de memoria virtual (VMA) y la cantidad de archivos abiertos para el proceso de Firebird.
1. VMAEl número predeterminado de VMA es 64K, se debe aumentar 4 veces, para esto, agregue la línea en sysctl.conf
vm.max_map_count=262144
Para verificar el valor actual, use el comando
sysctl vm.max_map_count
2. Max archivos abiertosFirebird abre hasta 20 descriptores (identificadores de archivos) para cada conexión a la base de datos (considerando el hecho de que en Linux todos los recursos parecen archivos), por lo que el número máximo de archivos abiertos por defecto (generalmente 4096) puede agotarse muy rápidamente.
Para verificar la cantidad de archivos disponibles para Firebird, es mejor mirar los límites del archivo ejecutable de Firebird:
cat /proc/$(pgrep firebird)/limits
dónde verificar el valor de Max Open Files y aumentarlos si es necesario.
Para aumentar el parámetro Max Open Files para Firebird, agregamos la línea al archivo firebird-superserver.service en la sección [servicio]:
LimitNOFILE=49999
Configuración opcional de Linux
En este servidor, también hicimos las siguientes configuraciones
1. Intercambio reducidoDado que el servidor está dedicado exclusivamente al Firebird DBMS, y queremos usar la RAM de manera eficiente bajo el caché DBMS y el caché de archivos del sistema operativo, reducimos el intercambio del 60% al 10% predeterminado, para esto agregamos sysctl.conf
vm.swappiness=10
2. Aumentó el tamaño mínimo de memoria reservada para procesos especiales del sistema operativo vm.min_free_kbytes=1048576
es decir, 1 GB de memoria. Esta configuración afecta indirectamente a la desfragmentación de la memoria.
Tenga en cuenta que esta configuración es individual, dado que tenemos 320 GB de RAM, 1 GB no es tanto, pero en el caso de una pequeña cantidad de memoria (por ejemplo, 32 GB), 1 GB podría ser demasiado.
3. Keepalive reducidoFirebird se basa en intervalos keepalive para verificar el estado de la conexión, y el valor predeterminado de keepalive puede ser muy grande. Limitándolo a 300 segundos, nos deshacemos de las conexiones colgantes
net.ipv4.tcp_keepalive_time=300 net.ipv4.tcp_keepalive_probes=5 net.ipv4.tcp_keepalive_intvl=15
Más ajustes de Linux
¿Por qué estamos limitados a un número tan pequeño de configuraciones de Linux?
En primer lugar, adoptamos un enfoque conservador para ajustar los servidores con Linux (que está mejorando cada vez más con cada nueva versión), en segundo lugar, esta base de datos Firebird no es extremadamente grande ni la más cargada, y Linux hace frente a la configuración especificada con tus tareas
Por supuesto, hay algunas configuraciones más que se pueden usar para optimizar el trabajo de Firebird en Linux; por ejemplo, se presentaron varias cosas interesantes en la
presentación sobre la base de datos Firebird de 3 TB (RedBaza) en el Servicio Federal de Alguaciles.
Configurar Firebird
Los archivos de configuración de la comunidad Firebird con firebirdsql.org se configuran de manera muy conservadora, y en un servidor más o menos potente necesita cambiar los archivos de configuración y seleccionar cuidadosamente la arquitectura utilizada (en Firebird 3.0 hay 2 tipos de conexiones: Embedded y NetworkServer, y 3 tipos de arquitecturas: SuperServer , Superclásico, Clásico).
Además, debe usar la configuración para cada base de datos, es decir poner configuraciones críticas en database.conf, con referencia a una base de datos específica.
En nuestro caso, elegimos la arquitectura SuperServer, la más popular en la versión 3.0, porque utiliza eficientemente procesadores de múltiples núcleos y tiene un caché compartido para todas las conexiones (pero separado para cada base de datos).
Los siguientes son los archivos de configuración (solo valores relacionados con el rendimiento):
firebird.conf: archivo de configuración para todas las bases de datos en el servidor DefaultDbCachePages = 50K # pages FileSystemCacheThreshold = 300K # pages TempBlockSize = 2M # bytes TempCacheLimit = 20480M # bytes LockMemSize = 30M # bytes LockHashSlots = 30011 WireCompression = true ServerMode = Super ExtConnPoolSize = 500 # HQBird ExtConnPoolLifeTime = 14200 # HQBird SortDataStorageThreshold = 8192 #HQbird reports queries
En términos de rendimiento, los parámetros clave aquí son:
1. DefaultDbCachePages = 50K # se mide en páginas, en una base de datos, en la página 16K = 0.8GbEl tamaño de la memoria caché de la página DefaultDbCachePages en firebird.conf está especialmente configurado de manera predeterminada en 800Mb para que la base de datos de prueba desordenada accidentalmente en el servidor no intente ocupar una gran cantidad de RAM.
2. FileSystemCacheThreshold = 300K # páginasEs importante establecer este parámetro en un valor mayor que DefaultDBCachePages para permitir el uso de la memoria caché del archivo del sistema operativo.
3. TempCacheLimit = 20480M # bytesEste parámetro establece el tamaño de la memoria para consultas con tipos (y algunas otras operaciones), y es individual para cada sistema.
Como resultado de monitorear el tamaño, descubrimos que 20GB es óptimo para esta base de datos.
4. LockMemSize y LockHashSlots: parámetros de la tabla de bloqueoEstos parámetros determinan el tamaño inicial de la tabla de bloqueo y el número de ranuras para calcular la función hash.
5. WireCompression = TrueAl configurar el tráfico comprimido entre clientes y servidores, esto es especialmente útil con la instrucción de ejecución intensiva externa, que ejecuta la aplicación cliente.
Los parámetros restantes se describen en firebird.conf y la documentación relacionada de Firebird y HQbird.
Realizamos las configuraciones más importantes en
database.conf , con la base de datos exacta
database1 = /data/database1.fdb { DefaultDbCachePages = 14080K # 16K pages, 220 GB FileSystemCacheThreshold = 15361K TempSpaceCacheThreshold=2G #HQbird only, track big sorts LockHashSlots = 40099 LockMemSize = 50M }
Como puede adivinar, la principal dificultad en este caso es cómo calcular correctamente el tamaño de la memoria asignada por nuestra gran base de datos.
Para Firebird 3.0 con arquitectura SuperServer, hay dos enfoques: conservador, que se utiliza en servidores con una pequeña cantidad de RAM (hasta 32 GB inclusive), que consiste en asignar no más del 25% de RAM para la memoria caché de páginas, y el resto depende del sistema operativo de archivos sistemas y ajustes, cuando determinamos con precisión el tamaño óptimo para las clases, asignamos un cierto tamaño de memoria para el núcleo del sistema operativo, reservamos una cierta cantidad de memoria para operaciones masivas de archivos (por ejemplo, copia de seguridad), el resto asignado para la caché de páginas.
En el segundo caso, no es posible obtener inmediatamente el tamaño de caché óptimo, ya que la naturaleza de la carga puede diferir mucho para los diferentes tipos de bases de datos, pero después de varias iteraciones puede lograr un resultado excelente.
Errores comunes en la configuración de Firebird
Los errores típicos incluyen lo siguiente:
1) El tamaño de la memoria caché de la página especificada explícitamente en la página del encabezado de la base de datos, que anula los valores especificados en firebird.conf y database.conf.
Especialmente a menudo, este error ocurre cuando se cambia la arquitectura de Classic / SuperClassic a SuperServer: si el tamaño de caché para la conexión Classic / SuperClassic funciona bien con un tamaño pequeño claramente indicado (500-2000 páginas), entonces se necesita un caché mucho más grande para SuperServer.
Para verificar, ejecute el comando
gstat -h databasepathname
y verifique el valor de
Page Buffers : debe ser 0, luego Firebird usará los valores de database.conf o firebird.conf.
Para restablecer la configuración de caché de página en la página de encabezado, ejecute el comando
gfix -buff 0 databasepathname
2) Al aumentar la memoria caché de la página, se olvidan de aumentar el FileSystemCacheThreshold, lo que conduce a la desconexión de la memoria caché del archivo, lo que reduce el rendimiento.
3) Usando el tamaño de página predeterminado de la base de datos (4096 u 8192), mientras que para bases de datos grandes necesita usar 16K.
Conclusión
En general, más de 1000 usuarios de Firebird en hierro, correspondientes a la carga configurada por Linux y configurada por Firebird, trabajan sin problemas. Hay un margen en este servidor en términos de rendimiento, que se probó en cargas máximas para hasta 1500-1800 usuarios.
Entre las distribuciones de Linux para la base de datos Firebird con una carga similar, la más popular es CentOS 7, la versión recomendada es Firebird 3.0.
Si tiene alguna pregunta, me complacerá responder en los comentarios, o por correo electrónico ak@ibase.ru.