Le noyau Linux fournit une large gamme d'options de configuration pouvant affecter les performances. L'essentiel est de choisir la bonne configuration pour votre application et votre charge de travail. Comme toute autre base de données, PostgreSQL a besoin d'un réglage optimal du noyau Linux. Des paramètres incorrects peuvent entraîner de mauvaises performances. Il est important d'effectuer une analyse comparative des performances de la base de données après chaque session de réglage. Dans l'un de mes précédents articles intitulé «Ajuster les paramètres du noyau Linux pour l'optimisation de PostgreSQL», j'ai décrit certains des paramètres du noyau Linux les plus utiles et comment ils aident à améliorer les performances de la base de données. Je vais maintenant partager les résultats des tests comparatifs après avoir configuré HugePages sur Linux sous diverses charges PostgreSQL. J'ai mené une suite de tests complète sous de nombreuses charges de travail PostgreSQL différentes avec un nombre différent de clients simultanés.
PC sur lequel les tests ont été effectués
- Serveur Supermicro:
- Processeur Intel® Xeon® E5-2683 v3 à 2,00 GHz
- 2 supports / 28 cœurs / 56 fils
- Mémoire: 256 Go de RAM
- Stockage: SSD d'entreprise SAMSUNG SM863 1,9 To
- Système de fichiers: ext4 / xfs
- OS: Ubuntu 16.04.4, noyau 4.13.0-36-générique
- PostgreSQL: version 11
Paramètres du noyau Linux
J'ai utilisé les paramètres du noyau par défaut sans aucune optimisation / modification, uniquement les HugePages transparentes désactivées. Cette technologie est activée par défaut et alloue des pages dont la taille n'est pas recommandée pour une utilisation avec des bases de données. En général, les bases de données ont besoin de HugePages d'une taille fixe, mais Transparent HugePages ne peut pas les fournir. Par conséquent, il est toujours recommandé de désactiver cette fonctionnalité et d'installer par défaut les HugePages classiques.
Paramètres PostgreSQL
J'ai utilisé les mêmes paramètres PostgreSQL pour tous les tests pour enregistrer différentes charges de travail PostgreSQL avec différents paramètres Linux HugePages. Pour tous les tests, les paramètres PostgreSQL suivants ont été appliqués:
shared_buffers = '64GB' work_mem = '1GB' random_page_cost = '1' maintenance_work_mem = '2GB' synchronous_commit = 'on' seq_page_cost = '1' max_wal_size = '100GB' checkpoint_timeout = '10min' synchronous_commit = 'on' checkpoint_completion_target = '0.9' autovacuum_vacuum_scale_factor = '0.4' effective_cache_size = '200GB' min_wal_size = '1GB' wal_compression = 'ON'
Schéma de test
Le schéma de test joue un rôle important. Tous les tests sont effectués trois fois, la durée de chaque cycle est de 30 minutes. Sur la base des résultats de ces 3 tests, j'ai déduit la valeur moyenne. Les tests ont été effectués à l'aide de l'outil pgbench de PostgreSQL; il fonctionne avec un facteur d'échelle par incréments d'environ 16 Mo de charge.
Hugepages
Par défaut, Linux utilise des pages de mémoire 4K, ainsi que la technologie HugePages. BSD utilise la technologie Super Pages et Windows utilise les grandes pages. PostgreSQL prend uniquement en charge la technologie HugePages (Linux). Dans les cas où la quantité de mémoire utilisée est importante, des pages plus petites réduisent les performances. À l'aide de HugePages, vous augmentez la mémoire allouée à l'application et, par conséquent, réduisez la «surcharge» qui se produit pendant le processus d'allocation / échange. Ainsi, les HugePages augmentent la productivité.
Voici les paramètres des HugePages de 1 Go. Ces informations sont disponibles à tout moment en utilisant / proc.
AnonHugePages: 0 kB ShmemHugePages: 0 kB HugePages_Total: 100 HugePages_Free: 97 HugePages_Rsvd: 63 HugePages_Surp: 0 Hugepagesize: 1048576 kB
J'ai écrit plus sur HugePages dans un post précédent.
https://www.percona.com/blog/2018/08/29/tune-linux-kernel-parameters-for-postgresql-optimization/
En général, les HugePages ont une taille de 2 Mo et 1 Go, il est donc logique d'utiliser 1 Go.
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/performance_tuning_guide/s-memory-transhuge
https://kerneltalks.com/services/what-is-huge-pages-in-linux/
Résultats des tests
Ce test montre l'effet global de l'utilisation de HugePages de différentes tailles. La première suite de tests a été créée avec une taille de page 4K - utilisée par défaut sous Linux - et sans activation HugePages. Je vous rappelle que j'ai désactivé l'option Transparent HugePages pendant toute la durée des tests.
Ensuite, un deuxième ensemble de tests a été effectué pour les HugePages d'une taille de 2 Mo. Enfin, une troisième série de tests a été exécutée pour les HugePages de 1 Go.
Pour tous les tests comparatifs, nous avons utilisé le SGBD PostgreSQL 11. Les kits comprennent des combinaisons de différentes tailles de bases de données et de divers clients. Le graphique ci-dessous montre les résultats d'une comparaison des performances à l'aide de ces tests: TPS (nombre de transactions par seconde) - le long de l'axe Y, et la taille de la base de données et le nombre de clients pour une base de données d'une certaine taille - le long de l'axe X.
Le graphique ci-dessus montre que, grâce à l'utilisation de HugePages, le gain augmente à mesure que le nombre de clients et la taille de la base de données augmentent, tant que cette taille reste dans le tampon partagé pré-alloué.
Ce test a comparé TPS et le nombre de clients. Dans ce cas, la taille de la base de données est de 48 Go. L'axe Y indique TPS et l'axe X indique le nombre de clients connectés. La taille de la base de données est suffisamment petite pour tenir dans un tampon partagé avec une taille fixe de 64 Go.
Lorsque HugePages fait 1 Go, le gain de performances comparatif augmente avec le nombre de clients.
Le graphique suivant est le même que le précédent, mais la taille de la base de données est de 96 Go. C'est plus grand que la taille totale de tampon fixe de 64 Go.
La principale chose à noter ici: les performances avec des HugePages de 1 Go augmentent à mesure que le nombre de clients augmente et, finalement, offrent de meilleures performances que l'utilisation de HugePages de 2 Mo ou de pages standard de 4 Ko.
Ce test montre le rapport entre TPS et la taille de la base de données. Dans ce cas, le nombre de clients connectés est de 32. Sur l'axe Y, TPS est affiché, et sur l'axe X, la taille de la base de données.
Comme prévu, lorsque la taille de la base de données dépasse la taille des HugePages préallouées, les performances sont considérablement réduites.
Conclusion
L'une de mes principales recommandations est de désactiver les HugePages transparentes. Vous obtiendrez la plus grande amélioration des performances si la base de données est placée dans un tampon partagé avec HugePages activé. La taille optimale de HugePages est déterminée par essais et erreurs, mais cette approche peut potentiellement entraîner un gain significatif en TPS, lorsque la taille de la base de données est suffisamment grande, mais en même temps lui permet de tenir dans un tampon commun.