Les performances optimales de PostgreSQL dépendent de paramètres de système d'exploitation correctement définis. Des paramètres de noyau de système d'exploitation mal réglés peuvent dégrader les performances du serveur de base de données. Par conséquent, il est impératif que ces paramètres soient configurés en fonction du serveur de base de données et de sa charge de travail. Dans cet article, nous discuterons de certains paramètres importants du noyau Linux qui peuvent affecter les performances du serveur de base de données et comment les régler.
SHMMAX / SHMALL
SHMMAX est un paramètre de noyau utilisé pour déterminer la taille maximale d'un segment de mémoire partagée unique qu'un processus Linux peut allouer. Avant la version 9.2, PostgreSQL utilisait System V (SysV), qui nécessite une configuration SHMMAX. Après 9.2, PostgreSQL est passé à la mémoire partagée POSIX. Alors maintenant, moins d'octets de mémoire partagée System V sont nécessaires.
Avant la version 9.3, SHMMAX était le paramètre de noyau le plus important. La valeur SHMMAX est spécifiée en octets.
De même,
SHMALL est un autre paramètre du noyau utilisé pour déterminer
pages de mémoire partagée à l'échelle du système. Utilisez la commande
ipcs pour afficher les valeurs SHMMAX, SHMALL ou SHMMIN actuelles.
Détails SHM * - Linux$ ipcs -lm ------ Shared Memory Limits -------- max number of segments = 4096 max seg size (kbytes) = 1073741824 max total shared memory (kbytes) = 17179869184 min seg size (bytes) = 1
Détails SHM * - MacOS X $ ipcs -M IPC status from as of Thu Aug 16 22:20:35 PKT 2018 shminfo: shmmax: 16777216 (max shared memory segment size) shmmin: 1 (min shared memory segment size) shmmni: 32 (max number of shared memory identifiers) shmseg: 8 (max shared memory segments per process) shmall: 1024 (max amount of shared memory in pages)
PostgreSQL utilise
IPC System V pour allouer la mémoire partagée. Ce paramètre est l'un des paramètres de noyau les plus importants. Chaque fois que vous recevez les messages d'erreur suivants, cela signifie que vous disposez d'une ancienne version de PostgreSQL et que votre valeur SHMMAX est très faible. Il est prévu que les utilisateurs ajusteront et augmenteront la valeur en fonction de la mémoire partagée qu'ils vont utiliser.
Erreurs de mauvaise configuration possibles
Si SHMMAX n'est pas configuré correctement, vous pouvez recevoir une erreur lorsque vous essayez d'initialiser un cluster PostgreSQL à l'aide de la commande
initdb .
échec initdbDETAIL: Failed system call was shmget(key=1, size=2072576, 03600).
HINT: This error usually means that PostgreSQL's request for a shared memory segment exceeded your kernel's SHMMAX parameter.
You can either reduce the request size or reconfigure the kernel with larger SHMMAX. To reduce the request size (currently 2072576 bytes),
reduce PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.
If the request size is already small, it's possible that it is less than your kernel's SHMMIN parameter,
in which case raising the request size or reconfiguring SHMMIN is called for.
The PostgreSQL documentation contains more information about shared memory configuration. child process exited with exit code 1De même, vous pouvez recevoir une erreur lors du démarrage du serveur PostgreSQL à l'aide de la commande
pg_ctl .
échec de pg_ctlDETAIL: Failed system call was shmget(key=5432001, size=14385152, 03600).
HINT: This error usually means that PostgreSQL's request for a shared memory segment exceeded your kernel's SHMMAX parameter.
You can either reduce the request size or reconfigure the kernel with larger SHMMAX.; To reduce the request size (currently 14385152 bytes), reduce PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.
If the request size is already small, it's possible that it is less than your kernel's SHMMIN parameter,
in which case raising the request size or reconfiguring SHMMIN is called for.
The PostgreSQL documentation contains more information about shared memory configuration.Comprendre les différences dans les définitions
La définition des paramètres SHMMAX / SHMALL est légèrement différente sous Linux et MacOS X:
- Linux: kernel.shmmax, kernel.shmall
- MacOS X: kern.sysv.shmmax, kern.sysv.shmall
La commande
sysctl peut être utilisée pour modifier temporairement une valeur. Pour définir des valeurs constantes, ajoutez une entrée dans
/etc/sysctl.conf . Les détails sont donnés ci-dessous.
Modifier les paramètres du noyau sur MacOS X # Get the value of SHMMAX sudo sysctl kern.sysv.shmmax kern.sysv.shmmax: 4096 # Get the value of SHMALL sudo sysctl kern.sysv.shmall kern.sysv.shmall: 4096 # Set the value of SHMMAX sudo sysctl -w kern.sysv.shmmax=16777216 kern.sysv.shmmax: 4096 -> 16777216 # Set the value of SHMALL sudo sysctl -w kern.sysv.shmall=16777216 kern.sysv.shmall: 4096 -> 16777216
Modification des paramètres du noyau Linux # Get the value of SHMMAX sudo sysctl kernel.shmmax kernel.shmmax: 4096 # Get the value of SHMALL sudo sysctl kernel.shmall kernel.shmall: 4096 # Set the value of SHMMAX sudo sysctl -w kernel.shmmax=16777216 kernel.shmmax: 4096 -> 16777216 # Set the value of SHMALL sudo sysctl -w kernel.shmall=16777216 kernel.shmall: 4096 -> 16777216
N'oubliez pas : pour rendre les modifications permanentes, ajoutez ces valeurs à /etc/sysctl.confGrandes pages (grandes pages)
Linux utilise par défaut des pages 4K, BSD utilise des
Super Pages et Windows utilise de
grandes pages . Une page est un morceau de RAM alloué à un processus. Un processus peut avoir plusieurs pages, selon les besoins en mémoire. Plus un processus a besoin de mémoire, plus il a été alloué de pages. Le système d'exploitation prend en charge une table d'allocation de pages pour les processus. Plus la taille de la page est petite, plus le tableau est grand, plus il faut de temps pour trouver une page dans ce tableau de pages. Par conséquent, les grandes pages vous permettent d'utiliser une grande quantité de mémoire avec une surcharge réduite; moins de pages vues, moins d'erreurs de page, des opérations de lecture / écriture plus rapides grâce à de grands tampons. Le résultat est une amélioration des performances.
PostgreSQL ne prend en charge que les grandes pages sous Linux. Par défaut, Linux utilise 4 Ko de pages de mémoire, donc si vous avez trop d'opérations de mémoire, vous devez installer des pages plus grandes. Il y a un gain de performances lors de l'utilisation de grandes pages de 2 Mo et jusqu'à 1 Go. Une grande taille de page peut être définie au démarrage. Vous pouvez facilement vérifier les paramètres de la grande page et leur utilisation sur votre ordinateur Linux en utilisant la commande
cat / proc / meminfo | grep -i énorme .
Obtention d'informations sur les grandes pages (Linux uniquement) Note: This is only for Linux, for other OS this operation is ignored$ cat /proc/meminfo | grep -i huge AnonHugePages: 0 kB ShmemHugePages: 0 kB HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB
Dans cet exemple, bien que la taille de la grande page soit définie sur 2048 (2 Mo), le nombre total de grandes pages est de 0. Cela signifie que les grandes pages sont désactivées.
Script pour déterminer le nombre de grandes pages
Ce script simple renvoie le nombre requis de grandes pages. Exécutez le script sur votre serveur Linux pendant l'exécution de PostgreSQL. Vérifiez que le répertoire de données PostgreSQL est défini pour la variable d'environnement
$ PGDATA .
Obtenir le nombre de grandes pages requises
La sortie du script est la suivante:
Sortie de script Pid: 12737 VmPeak: 180932 kB Hugepagesize: 2048 kB Set Huge Pages: 88
La valeur recommandée pour les grandes pages est 88, vous devez donc la définir sur 88.
Installer de grandes pages sysctl -w vm.nr_hugepages=88
Vérifiez les grandes pages maintenant, vous verrez que les grandes pages ne sont pas utilisées (HugePages_Free = HugePages_Total).
Informations sur les grandes pages à nouveau (Linux uniquement) $ cat /proc/meminfo | grep -i huge AnonHugePages: 0 kB ShmemHugePages: 0 kB HugePages_Total: 88 HugePages_Free: 88 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB
Maintenant, définissez énorme_pages «on» sur $ PGDATA / postgresql.conf et redémarrez le serveur.
Et encore une fois, des informations sur les grandes pages (Linux uniquement) $ cat /proc/meminfo | grep -i huge AnonHugePages: 0 kB ShmemHugePages: 0 kB HugePages_Total: 88 HugePages_Free: 81 HugePages_Rsvd: 64 HugePages_Surp: 0 Hugepagesize: 2048 kB
Vous pouvez maintenant voir que très peu de grandes pages sont utilisées. Essayons maintenant d'ajouter des données à la base de données.
Quelques opérations de base de données pour le recyclage de grandes pages postgres=
Voyons voir si nous utilisons des pages plus grandes maintenant qu'auparavant.
Encore une fois des informations sur de grandes pages (Linux uniquement) $ cat /proc/meminfo | grep -i huge AnonHugePages: 0 kB ShmemHugePages: 0 kB HugePages_Total: 88 HugePages_Free: 18 HugePages_Rsvd: 1 HugePages_Surp: 0 Hugepagesize: 2048 kB
Vous pouvez maintenant voir que la plupart des grandes pages sont en cours d'utilisation.
Remarque: la valeur approximative des HugePages utilisées ici est très faible, ce qui n'est pas une valeur normale pour une machine dans un environnement alimentaire. Veuillez évaluer le nombre de pages requis pour votre système et les définir en fonction de la charge et des ressources.vm.swappiness
vm.swappiness est un autre paramètre du noyau qui peut affecter les performances de la base de données. Ce paramètre est utilisé pour contrôler le comportement d'échange (échange de pages vers et depuis la mémoire) sous Linux. La valeur va de 0 à 100. Elle détermine la quantité de mémoire qui sera déchargée ou déchargée. Zéro signifie désactiver l'échange et 100 signifie échange agressif.
Vous pouvez obtenir de bonnes performances en définissant des valeurs inférieures.
Si vous définissez la valeur sur 0 dans les noyaux plus récents, OOM Killer (processus de nettoyage de la mémoire Linux) peut tuer le processus. Ainsi, vous pouvez définir la valeur sur 1 en toute sécurité si vous souhaitez minimiser l'échange. La valeur par défaut sous Linux est 60. Une valeur plus élevée fait que la MMU (unité de gestion de la mémoire) utilise plus d'espace de pagination que la RAM, tandis qu'une valeur plus basse enregistre plus de données / code en mémoire.
Une valeur inférieure est un bon pari sur l'amélioration des performances dans PostgreSQL.
vm.overcommit_memory / vm.overcommit_ratio
Les applications reçoivent de la mémoire et la libèrent lorsqu'elle n'est plus nécessaire. Mais dans certains cas, l'application obtient trop de mémoire et ne la libère pas. Cela peut provoquer un tueur OOM. Voici les valeurs possibles pour le paramètre
vm.overcommit_memory avec une description pour chacune:
- Surcharge heuristique (par défaut); heuristique basée sur le noyau
- Autorisez quand même le surengagement
- N'en faites pas trop, ne dépassez pas le ratio de surengagement.
Lien: https://www.kernel.org/doc/Documentation/vm/overcommit-accountingvm.overcommit_ratio - pourcentage de RAM disponible pour la surcharge. Une valeur de 50% dans un système avec 2 Go de RAM peut allouer jusqu'à 3 Go de RAM.
Une valeur de 2 pour vm.overcommit_memory offre de meilleures performances pour PostgreSQL. Cette valeur maximise l'utilisation de la RAM par le processus serveur sans risque significatif d'être tué par le processus de tueur OOM. L'application pourra redémarrer, mais uniquement dans les limites des dépenses excessives, ce qui réduit le risque que le tueur OOM ne tue le processus. Par conséquent, une valeur de 2 donne de meilleures performances que la valeur par défaut de 0. Cependant, la fiabilité peut être améliorée en garantissant que la mémoire en dehors de la plage acceptable n'est pas surchargée. Cela élimine le risque que le processus soit tué par le tueur OOM.
Sur les systèmes sans pagination, un problème peut se produire avec vm.overcommit_memory égal à 2.
https://www.postgresql.org/docs/current/static/kernel-resources.html#LINUX-MEMORY-OVERCOMMITvm.dirty_background_ratio / vm.dirty_background_bytes
vm.dirty_background_ratio est le pourcentage de mémoire remplie de pages sales qui doivent être écrites sur le disque. Réinitialisez sur le disque en arrière-plan. La valeur de ce paramètre est comprise entre 0 et 100; cependant, une valeur inférieure à 5 peut être inefficace et certains noyaux ne la prennent pas en charge. 10 est la valeur par défaut sur la plupart des systèmes Linux. Vous pouvez améliorer les performances pour les opérations d'enregistrement intensives à un taux inférieur, ce qui signifie que Linux videra les pages sales en arrière-plan.
Vous devez définir la valeur de
vm.dirty_background_bytes en fonction de la vitesse de votre disque.
Il n'y a pas de «bonnes» valeurs pour ces deux paramètres, car les deux dépendent du matériel. Cependant, la définition de vm.dirty_background_ratio sur 5 et vm.dirty_background_bytes à 25% de la vitesse du disque augmentera les performances à ~ 25% dans la plupart des cas.
vm.dirty_ratio / dirty_bytes
C'est la même chose que
vm.dirty_background_ratio / dirty_background_bytes , sauf que la réinitialisation est effectuée dans une session de travail, bloquant l'application. Par conséquent, vm.dirty_ratio doit être supérieur à
vm.dirty_background_ratio . Cela garantit que les processus d'arrière-plan démarreront plus tôt afin d'éviter autant que possible de bloquer l'application. Vous pouvez ajuster la différence entre ces deux ratios en fonction de la charge d'E / S du disque.
Résumé
Vous pouvez configurer d'autres paramètres pour augmenter la productivité, mais les améliorations seront minimes et vous n'obtiendrez pas beaucoup d'avantages. Nous devons nous rappeler que tous les paramètres ne s'appliquent pas à tous les types d'applications. Certaines applications fonctionnent mieux lorsque nous configurons certains paramètres, d'autres non. Vous devez trouver le bon équilibre entre les configurations de ces paramètres pour la charge de travail attendue et le type d'application, et lors de la configuration, vous devez prendre en compte le comportement du système d'exploitation. La configuration des paramètres du noyau n'est pas aussi simple que le réglage des paramètres de la base de données: il est plus difficile de donner vos recommandations ici.