Optimisation de Firebird et Linux pour une base de données de 691 Go avec plus de 1000 utilisateurs

Firebird est un SGBD ouvert très populaire en Russie, et malgré l'absence de campagnes de marketing bruyantes, il est utilisé dans un grand nombre de systèmes critiques, en particulier dans les systèmes d'automatisation médicaux et d'État.

La taille de la base de données et le nombre d'utilisateurs actifs dans de tels systèmes sont généralement assez importants, donc dans cet article, je parlerai de l'expérience de l'optimisation des paramètres Firebird et Linux sur la base d'exemples spécifiques de grandes bases de données Firebird à BeZdorov (Ingosstrakh), AlfaZdrav , et je parlerai de l' expérience d'autres sociétés d'optimisation Firebird + Linux.

Examinons de plus près le sujet de l'optimisation - Firebird 3.0.5 DBMS (avec extensions HQbird), sert une base de données de 691 Go (actuellement) avec 1000-1100 utilisateurs quotidiens, fonctionne sur Linux CentOS 7, le serveur utilise un fer HP DL380. La réplication vers le serveur de sauvegarde est configurée pour la base de données (la question de la réplication sort du cadre de cet article).

Le SGBD dessert le système d'information médicale Infoklinika (produit par la société russe Smart Delta Systems ), qui est l'un des systèmes d'information médicale les plus populaires en Russie.

Jetons un coup d'œil aux détails (les captures d'écran sont extraites de HQbird plus tard) du fonctionnement de cette base de données:

Les données sont insérées de manière intensive dans la base de données - un gain quotidien d'environ 0,4 à 0,5 Go



1000-1100 connexions est la charge quotidienne habituelle:



Malgré une croissance intensive et un travail actif, la base de données ne contient pas de quantité significative de versions de déchets des enregistrements - à la fois grâce à des applications écrites avec une bonne connaissance de l'architecture multi-versions et en raison d'un garbage collection correctement configuré:



Marqueurs de transaction dans la zone verte:



Soit dit en passant, notez que les données dans la base de données sont des chaînes, des blobs sont présents, mais il y en a peu - seulement 10 Go sur 690 Go de la taille totale.

La nature de la charge de la base de données est mixte, 75% des opérations de lecture et 25% d'écriture:

Le fer

Le serveur qui dessert ce système n'est pas mauvais, mais loin d'être haut de gamme:

HP ProLiant DL380p Gen8, Gen8 2x Xeon(R) CPU E5v2 @ 2.60GHz, 24 logical cores with HT 320Gb RAM, 4 network cards 

Le sous-système de disque se compose de deux parties: un disque local de 745 Go et une double connexion Fibre Channel 2 vers le SAN, avec une partition de 1,8 To.

Système d'exploitation

Avec CentOS 7, version du noyau:

 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 

À la question logique, pourquoi le noyau le plus moderne et CentOS 8 ne sont pas utilisés, la réponse est également logique - la migration des systèmes critiques ne se produit qu'après la publication de plusieurs versions mineures et des tests rigoureux - c'est l'un de ces cas où un bogue connu vaut mieux que deux inconnues.

Cependant, il convient de noter que jusqu'en 2017, le système fonctionnait sur CentOS 6.x, et après la migration, une amélioration significative des indicateurs de performance a été constatée.

Configuration Linux

Une personnalisation Linux absolument essentielle pour Firebird

Il y a 2 paramètres qui doivent être augmentés sur tous les serveurs Linux sur lesquels Firebird fonctionne - le nombre de zones de mémoire virtuelle (VMA) et le nombre de fichiers ouverts pour le processus Firebird.

1. VMA

Le numéro VMA par défaut est 64 Ko, il doit être augmenté 4 fois, pour cela, ajoutez la ligne dans sysctl.conf

 vm.max_map_count=262144 

Pour vérifier la valeur actuelle, utilisez la commande

 sysctl vm.max_map_count 

2. Max fichiers ouverts

Firebird ouvre jusqu'à 20 descripteurs (descripteurs de fichiers) pour chaque connexion à la base de données (compte tenu du fait que sous Linux toutes les ressources ressemblent à des fichiers), le nombre maximal de fichiers ouverts par défaut (généralement 4096) peut donc être épuisé très rapidement.

Pour vérifier le nombre de fichiers disponibles pour Firebird, il est préférable de regarder les limites du fichier exécutable Firebird:

 cat /proc/$(pgrep firebird)/limits 

où vérifier la valeur de Max Open Files et les augmenter si nécessaire.

Pour augmenter le paramètre Max Open Files pour Firebird, nous avons ajouté la ligne au fichier firebird-superserver.service dans la section [service]:

 LimitNOFILE=49999 

Configuration Linux en option

Sur ce serveur, nous avons également effectué les réglages suivants

1. Échange réduit

Étant donné que le serveur est exclusivement dédié au SGBD Firebird et que nous voulons utiliser efficacement la RAM sous le cache du SGBD et le cache de fichiers du système d'exploitation, nous réduisons la perméabilité de 60% à 10% par défaut, pour cela nous avons ajouté sysctl.conf

 vm.swappiness=10 

2. Augmentation de la taille minimale de mémoire réservée pour les processus OS spéciaux

 vm.min_free_kbytes=1048576 

soit 1 Go de mémoire. Ce paramètre affecte indirectement la défragmentation de la mémoire.

Veuillez noter que ce paramètre est individuel - étant donné que nous avons 320 Go de RAM, 1 Go n'est pas tellement, mais dans le cas d'une petite quantité de mémoire (par exemple, 32 Go), 1 Go pourrait être trop.

3. Keepalive réduit

Firebird s'appuie sur des intervalles de keepalive pour vérifier l'état de la connexion, et la valeur par défaut de keepalive peut être très grande. En le limitant à 300 secondes, on se débarrasse des connexions suspendues

 net.ipv4.tcp_keepalive_time=300 net.ipv4.tcp_keepalive_probes=5 net.ipv4.tcp_keepalive_intvl=15 

Plus d'optimisation Linux

Pourquoi sommes-nous limités à un si petit nombre de paramètres Linux?

Premièrement, nous adoptons une approche conservatrice pour régler les serveurs avec Linux (qui s'améliore de plus en plus avec chaque nouvelle version), et deuxièmement, cette base de données Firebird n'est ni extrêmement grande ni la plus chargée, et Linux fait face aux paramètres spécifiés avec vos tâches.

Bien sûr, il existe plusieurs autres paramètres qui peuvent être utilisés pour optimiser Firebird sur Linux - par exemple, un certain nombre de choses intéressantes ont été présentées dans la présentation de la base de données Firebird 3 To (RedBaza) du Federal Bailiff Service.

Configurer Firebird

Les fichiers de configuration de la communauté Firebird avec firebirdsql.org sont configurés de manière très conservatrice, et sur un serveur plus ou moins puissant, vous devez modifier les fichiers de configuration et sélectionner soigneusement l'architecture utilisée (dans Firebird 3.0, il existe 2 types de connexions: Embedded et NetworkServer, et 3 types d'architectures: SuperServer , SuperClassic, Classic).
En outre, vous devez utiliser les paramètres de chaque base de données - c'est-à-dire mettre les paramètres critiques dans databases.conf, en référence à une base de données spécifique.

Dans notre cas, nous avons choisi l'architecture SuperServer, la plus populaire de la version 3.0, car il utilise efficacement des processeurs multicœurs et dispose d'un cache partagé pour toutes les connexions (mais séparé pour chaque base de données).

Voici les fichiers de configuration (valeurs liées aux performances uniquement):

firebird.conf - fichier de configuration pour toutes les bases de données sur le serveur

 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 termes de performances, les paramètres clés sont les suivants:

1. DefaultDbCachePages = 50K # il est mesuré en pages, sur une base de données, à la page 16K = 0.8Gb

La taille du cache de page DefaultDbCachePages dans firebird.conf est spécialement définie par défaut à 800 Mo afin que la base de données de test encombrée accidentellement sur le serveur n'essaye pas de prendre une énorme quantité de RAM.

2. FileSystemCacheThreshold = 300K # pages

Il est important de définir ce paramètre sur une valeur supérieure à DefaultDBCachePages afin de permettre l'utilisation du cache de fichiers du système d'exploitation.

3. TempCacheLimit = 20480M # octets

Ce paramètre définit la taille de la mémoire pour les requêtes avec tri (et certaines autres opérations) et est individuel pour chaque système.
À la suite de la surveillance de la taille des tris, nous avons constaté que 20 Go est optimal pour cette base de données.

4. LockMemSize et LockHashSlots - paramètres de la table de verrouillage

Ces paramètres déterminent la taille initiale de la table de verrouillage et le nombre d'emplacements pour le calcul de la fonction de hachage.

5. WireCompression = True

La configuration du trafic compressé entre les clients et les serveurs est particulièrement utile avec une instruction d'exécution intensive sur externe, qui exécute l'application cliente.

Les paramètres restants sont décrits dans firebird.conf lui-même et dans la documentation connexe de Firebird et HQbird.

Nous avons effectué les réglages les plus importants dans databases.conf , avec la base de données exacte

 database1 = /data/database1.fdb { DefaultDbCachePages = 14080K # 16K pages, 220 GB FileSystemCacheThreshold = 15361K TempSpaceCacheThreshold=2G #HQbird only, track big sorts LockHashSlots = 40099 LockMemSize = 50M } 

Comme vous pouvez le deviner, la principale difficulté dans ce cas est de savoir comment calculer correctement la taille de la mémoire allouée par notre grande base de données.

Pour Firebird 3.0 avec architecture SuperServer, il existe deux approches - conservatrice, qui est utilisée sur les serveurs avec une petite quantité de RAM (jusqu'à 32 Go inclus), qui consiste à allouer pas plus de 25% de RAM pour le cache de pages, et le reste dépend du système d'exploitation de fichiers systèmes, et le réglage fin, lorsque nous déterminons précisément la taille optimale pour le tri, allouons une certaine taille de mémoire pour le noyau du système d'exploitation, réservons une certaine quantité de mémoire pour les opérations de fichiers massives (par exemple, la sauvegarde), le reste alloué pour le cache de page.

Dans le deuxième cas, il n'est pas possible d'obtenir immédiatement la taille de cache optimale, car la nature de la charge peut différer considérablement pour différents types de bases de données, mais après plusieurs itérations, vous pouvez obtenir un excellent résultat.

Erreurs courantes dans la configuration de Firebird

Les erreurs typiques sont les suivantes:

1) La taille du cache de page spécifiée explicitement sur la page d'en-tête de base de données, qui remplace les valeurs spécifiées dans firebird.conf et databases.conf.

Cette erreur se produit particulièrement souvent lors du changement d'architecture de Classic / SuperClassic en SuperServer - si la taille du cache pour la connexion Classic / SuperClassic fonctionne correctement avec une petite taille clairement indiquée (500-2000 pages), alors un cache beaucoup plus grand est nécessaire pour SuperServer.
Pour vérifier, exécutez la commande

 gstat -h databasepathname 

et vérifiez la valeur des Page Buffers - elle doit être 0, puis Firebird utilisera les valeurs de databases.conf ou firebird.conf.

Pour réinitialiser le paramètre de cache de page sur la page d'en-tête, exécutez la commande

 gfix -buff 0 databasepathname 

2) Lors de l'augmentation du cache de pages, ils oublient d'augmenter le FileSystemCacheThreshold, ce qui entraîne la déconnexion du cache de fichiers, ce qui réduit les performances.

3) Utilisation de la taille de page de base de données par défaut (4096 ou 8192), tandis que pour les grandes bases de données, vous devez utiliser 16 Ko.

Conclusion

En général, plus de 1000 utilisateurs Firebird sur fer, correspondant à la charge configurée par Linux et configurée par Firebird, fonctionnent sans problème. Il y a une marge sur ce serveur en termes de performances, qui a été testé à des charges de pointe pour jusqu'à 1500-1800 utilisateurs.

Parmi les distributions Linux pour la base de données Firebird avec une charge similaire, la plus populaire est CentOS 7, la version recommandée est Firebird 3.0.

Si vous avez des questions, je me ferai un plaisir de vous répondre dans les commentaires, ou par email ak@ibase.ru.