Le noyau Linux fournit une large gamme d'options de configuration pouvant affecter les performances. Il s'agit d'obtenir la bonne configuration pour votre application et votre charge de travail. Comme toute autre base de données, PostgreSQL utilise le noyau Linux pour une configuration optimale. Des paramètres mal réglés peuvent entraîner de mauvaises performances. Par conséquent, il est important de mesurer les performances de la base de données après chaque session de réglage pour éviter une dégradation des performances. Dans l'une de mes publications précédentes, «Réglage des 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 peuvent vous aider à améliorer les performances de la base de données. Je vais maintenant partager mes résultats de test après avoir configuré de grandes pages Linux avec une charge de travail PostgreSQL différente. J'ai effectué un ensemble exhaustif de tests pour différentes tailles de charge PostgreSQL et le nombre simultané de clients.
Machine d'essai
- 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 / réglage autre que la désactivation des grandes pages transparentes (Transparent HugePages). Les grandes pages transparentes sont activées par défaut et mettent en surbrillance la taille de la page, dont l'utilisation par la base de données peut ne pas être recommandée. Les bases de données nécessitent généralement de grandes pages de taille fixe qui ne sont pas couvertes par de grandes pages transparentes. Par conséquent, il est toujours recommandé de désactiver cette fonctionnalité et d'utiliser les grandes pages classiques par défaut.
Paramètres PostgreSQL
J'ai utilisé les paramètres PostgreSQL uniformes pour tous les tests pour enregistrer différentes charges de travail PostgreSQL avec différents paramètres pour les grandes pages Linux. Voici la configuration PostgreSQL utilisée pour tous les tests:
postgresql.confshared_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
Lors des tests, le programme de tests joue un rôle important. Tous les tests sont effectués trois fois pendant 30 minutes pour chaque cycle. J'ai pris la moyenne de ces trois indicateurs. Les tests ont été effectués à l'aide de l'outil de test de performances PostgreSQL
pgbench . pgbench fonctionne avec un facteur d'échelle, avec un facteur d'échelle d'environ 16 Mo de charge de travail.
Grandes pages (HugePages)
Linux, par défaut, utilise 4K pages de mémoire ainsi que de grandes pages. BSD a Super Pages, tandis que Windows a de grandes pages. PostgreSQL ne prend en charge que les grandes pages (Linux). En cas d'utilisation élevée de la mémoire, les petites pages réduisent les performances. En installant de grandes pages, vous augmentez la mémoire allouée à l'application et, par conséquent, réduisez les coûts opérationnels qui surviennent lors de l'allocation / l'échange; c'est-à-dire que vous augmentez la productivité en utilisant de grandes pages.
Voici la configuration pour les grandes pages lorsque vous utilisez une grande page de 1 Go. Vous pouvez toujours obtenir ces informations depuis / proc.
$ cat / proc / meminfo | grep -i énorme AnonHugePages: 0 kB ShmemHugePages: 0 kB HugePages_Total: 100 HugePages_Free: 97 HugePages_Rsvd: 63 HugePages_Surp: 0 Hugepagesize: 1048576 kB
Pour plus d'informations sur les grandes pages, veuillez lire mon précédent article de blog.
https://www.percona.com/blog/2018/08/29/tune-linux-kernel-parameters-for-postgresql-optimization/En règle générale, les grandes pages font 2 Mo et 1 Go, il est donc judicieux d'utiliser une taille de 1 Go au lieu d'une taille beaucoup plus petite de 2 Mo.
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/performance_tuning_guide/s-memory-transhugehttps://kerneltalks.com/services/what-is-huge-pages-in-linux/Résultats des tests
Ce test montre l'effet global de différentes tailles de grandes pages. La première suite de tests a été créée avec la taille de page par défaut sur Linux 4K sans inclure de grandes pages. Notez que les pages volumineuses transparentes ont également été désactivées et sont restées désactivées tout au long de tous ces tests.
Ensuite, la deuxième série de tests a été effectuée sur de grandes pages de 2 Mo. Enfin, la troisième série de tests s'exécute avec de grandes pages de 1 Go.
Tous ces tests ont été effectués dans PostgreSQL version 11. Les ensembles incluent une combinaison de différentes tailles de la base de données et des clients. Le graphique ci-dessous montre les résultats comparatifs des performances de ces tests avec TPS (transactions par seconde) le long de l'axe Y, la taille de la base de données et le nombre de clients par taille de la base de données le long de l'axe X.
Le graphique ci-dessus montre que le gain de performances avec de grandes pages augmente avec le nombre de clients et la taille de la base de données, si la taille reste dans le tampon précédemment alloué dans la mémoire partagée.
Ce test montre le TPS par rapport au nombre de clients. Dans ce cas, la taille de la base de données est de 48 Go. Sur l'axe Y, nous avons TPS, et sur l'axe X, nous avons le nombre de clients connectés. La taille de la base de données est suffisamment petite pour tenir dans un tampon partagé défini sur 64 Go.
Si les pages volumineuses sont définies sur 1 Go, plus il y a de clients, plus le gain de performances relatif est élevé.
Le graphique suivant est le même que celui ci-dessus, à l'exception de la taille de la base de données 96 Go. Cela dépasse la taille de la mémoire tampon partagée, qui est définie sur 64 Go.
L'observation clé ici est que les performances avec de grandes pages de 1 Go augmentent à mesure que le nombre de clients augmente, et en fin de compte, cela donne plus de performances que les grandes pages de 2 Mo ou la taille de page standard de 4 Ko.
Ce test montre TPS en fonction de la taille de la base de données. Dans ce cas, le nombre de clients connectés est de 32. Sur l'axe Y, nous avons TPS, et sur l'axe X - tailles de base de données.
Comme prévu, lorsque la base de données dépasse les grandes pages préallouées, les performances sont considérablement réduites.
Résumé
L'une de mes principales recommandations est de désactiver les HugePages transparentes. Vous verrez le gain de performances le plus important lorsque la base de données est placée dans un tampon partagé avec de grandes pages activées. Le choix de la taille des grandes pages nécessite une petite quantité d'essais et d'erreurs, mais cela peut potentiellement entraîner une augmentation significative du TPS lorsque la taille de la base de données est grande, mais reste suffisamment petite pour tenir dans un tampon partagé.