18.4. Gérer les ressources du noyau

La mémoire partagée et les sémaphores sont nommés collectivement « ipc system V » (ensemble avec les queues de messages, qui n'ont pas d'importance pour PostgreSQL™). Sauf sur Windows, où PostgreSQL™ fournit sa propre implémentation de remplacement de ces possibilités, elles sont requises pour que PostgreSQL™ puisse fonctionner.

Le manque complet de fonctionnalités est généralement manifesté par une erreur illegal system call au lancement du serveur. Dans ce cas, il n'y a rien à faire à part reconfigurer votre noyau. PostgreSQL™ ne fonctionnera pas sans. Néanmoins, cette situation est rare parmi les systèmes d'exploitation modernes.

Quand PostgreSQL™ dépasse une des nombreuses limites ipc, le serveur refusera de s'exécuter et lèvera un message d'erreur instructif décrivant le problème rencontré et que faire avec (voir aussi la Section 18.3.1, « Échecs de lancement »). Les paramètres adéquats du noyau sont nommés de façon cohérente parmi les différents systèmes ; le Tableau 18.1, « Paramètres system v ipc » donne un aperçu. Néanmoins, les méthodes pour les obtenir varient. Les suggestions pour quelques plateformes sont données ci-dessous.

PostgreSQL™ requiert quelques octets de mémoire partagée System V (typiquement 48 octets sur des plateformes 64 bits) pour chaque copie du serveur. Sur la plupart des systèmes d'exploitation modernes, cette quantité est facilement allouable. Néanmoins, si vous exécutez plusieurs copies du serveur ou si d'autres applications utilisent aussi de la mémoire partagée System V, il pourrait être nécessaire d'augmenter SHMMAX, correspondant à la taille maximale d'un segment de mémoire partagée, ou SHMALL, correspondant à la quantité totale de mémoire partagée System V pour tout le système. Notez que SHMALL est en nombre de blocs disques, et non pas en nombre d'octets sur de nombreux systèmes.

La taille minimum des segments de mémoire partagée (shmmin) est moins sensible aux problèmes. Elle devrait être au plus à environ 32 octets pour PostgreSQL™ (il est habituellement à 1). Le nombre maximum de segments au travers du système (shmmni) ou par processus (shmseg) a peu de chances de causer un problème sauf s'ils sont configurés à zéro sur votre système.

PostgreSQL™ utilise un sémaphore par connexion autorisée (max_connections), par processus autovacuum autorisé (autovacuum_max_workers) et par processus en tâche de fond autorisé réclamant un accès à la mémoire partagée, le tout par ensemble de 16. Chacun de ces ensembles contiendra aussi un 17è sémaphore qui contient un « nombre magique » pour détecter la collision avec des ensembles de sémaphore utilisés par les autres applications. Le nombre maximum de sémaphores dans le système est initialisé par semmns, qui en conséquence doit être au moins aussi haut que max_connections plus autovacuum_max_workers plus le nombre de processus en tâche de fond réclamant un accès à la mémoire partagée, plus un extra de chacune des 16 connexions autorisées et des processus autovacuum (voir la formule dans le Tableau 18.1, « Paramètres system v ipc »). Le paramètre semmni détermine la limite sur le nombre d'ensembles de sémaphores qui peuvent exister sur le système à un instant précis. Donc, ce paramètre doit être au moins égal à ceil((max_connections + autovacuum_max_workers + nombre de processus en tâche de fond + 5) / 16). Baisser le nombre de connexions autorisées est un contournement temporaire pour les échecs qui sont habituellement indiqués par le message « no space left on device », à partir de la fonction semget.

Dans certains cas, il pourrait être nécessaire d'augmenter semmap pour être au moins dans l'ordre de semmns. Si le système dispose de ce paramètre (ce n'est pas le cas pour beaucoup d'entre eux), ce paramètre définit la taille de la carte de ressources de sémaphores, dans laquelle chaque bloc contigü de sémaphores disponibles ont besoin d'une entrée. Lorsqu'un ensemble de sémaphores est libéré ou qu'il est enregistré sous une nouvelle entrée de carte. Si la carte est pleine, les sémaphores libérés sont perdus (jusqu'au redémarrage). La fragmentation de l'espace des sémaphores pourrait amener dans le temps à moins de sémaphores disponibles.

La paramètre semmsl, qui détermine le nombre de sémaphores dans un ensemble, pourrait valoir au moins 17 pour PostgreSQL™.

D'autres paramètres en relation avec l'« annulation de sémaphores », tels que semmnu et semume, n'affectent pas PostgreSQL™.

Si systemd™ est utilisé, une attention particulière doit être portée sur le fait que les ressources IPC (mémoire partagée et sémaphore) ne soient pas prématurément suppriméees par le système d'exploitation, et encore plus si l'installation de PostgreSQL s'est faite à partir des sources. Les utilisateurs des packages des distributions de PostgreSQL ont moins de risques d'être affectés car l'utilisateur postgres est normalement créé comme un utilisateur système.

La configuration RemoveIPC dans logind.conf contrôle si les objets IPC sont supprimés quand un utilisateur se déconnecte complètement. Les utilisateurs systèmes ne sont pas concernés. Ce paramètre est activé (on) par défaut avant la version originale de systemd™, mais certains systèmes d'exploitation choisissent de le configurer par défaut à off.

Un effet observé typiquement lorsque ce paramètre est activé est que les objets de la sémaphore utilisée par un serveur PostgreSQL sont supprimés à des moments aléatoires, amenant un arrêt brutal du serveur avec des messages dans les traces de ce type

LOG: semctl(1234567890, 0, IPC_RMID, ...) failed: Invalid argument
   

Les différents types d'objets IPC (mémoire partagée vs. sémaphores, System V vs. POSIX) sont traités légèrement différemment par systemd™, donc une personne pourrait observer que certaines ressources IPC ne sont pas supprimées de la même façon que les autres. De toute façon, il n'est pas conseillé de se baser sur ces différences subtiles.

Un événement du type « utilisateur se déconnectant » pourrait survenir dans le cadre d'un job de maintenance ou manuellement quand un administrateur se connecte avec l'utilisateur postgres ou quelque chose de similaire, donc il est difficile de l'empêcher en règle général.

Un « utilisateur système » est déterminé par systemd™ au moment de la compilation suivant la valeur du paramètre SYS_UID_MAX dans /etc/login.defs.

Les scripts des packages et de déploiements doivent faire attention à créer l'utilisateur postgres comme un utilisateur système en utilisant useradd -r, adduser --system, ou un équivalent.

Si le compte utilisateur a été créé de façon incorrect ou ne peut pas être modifié, il est recommendé de configurer

RemoveIPC=no
   

dans le fichier /etc/systemd/logind.conf ou dans tout autre fichier de configuration approprié.

Les systèmes d'exploitation style Unix renforcent différents types de limites de ressources qui pourraient interférer avec les opérations de votre serveur PostgreSQL™. Les limites sur le nombre de processus par utilisateur, le nombre de fichiers ouverts par un processus et la taille mémoire disponible pour chaque processus sont d'une grande importance. Chacun d'entre elles ont une limite « dure » et une limite « souple ». La limite souple est réellement ce qui compte mais cela pourrait être changé par l'utilisateur jusqu'à la limite dure. La limite dure pourrait seulement être modifiée par l'utilisateur root. L'appel système setrlimit est responsable de l'initialisation de ces paramètres. La commande interne du shell ulimit (shells Bourne) ou limit (csh) est utilisé pour contrôler les limites de ressource à partir de la ligne de commande. Sur les systèmes dérivés BSD, le fichier /etc/login.conf contrôle les différentes limites de ressource initialisées à la connexion. Voir la documentation du système d'exploitation pour les détails. Les paramètres en question sont maxproc, openfiles et datasize. par exemple :

default:\
...
        :datasize-cur=256M:\
        :maxproc-cur=256:\
        :openfiles-cur=256:\
...

(-cur est la limite douce. Ajoutez -max pour configurer la limite dure.)

Les noyaux peuvent aussi avoir des limites sur le système complet pour certaines ressources.

Le serveur PostgreSQL™ utilise un processus par connexion de façon à ce que vous puissiez fournir au moins autant de processus que de connexions autorisées, en plus de ce dont vous avez besoin pour le reste de votre système. Ceci n'est habituellement pas un problème mais si vous exécutez plusieurs serveurs sur une seule machine, cela pourrait devenir étroit.

La limite par défaut des fichiers ouverts est souvent initialisée pour être « amicalement sociale », pour permettre à de nombreux utilisateurs de coexister sur une machine sans utiliser une fraction inappropriée des ressources du système. Si vous lancez un grand nombre de serveurs sur une machine, cela pourrait être quelque chose que vous souhaitez mais sur les serveurs dédiés, vous pourriez vouloir augmenter cette limite.

D'un autre côté, certains systèmes autorisent l'ouverture d'un grand nombre de fichiers à des processus individuels ; si un plus grand nombre le font, alors les limites du système peuvent facilement être dépassées. Si vous rencontrez ce cas et que vous ne voulez pas modifier la limite du système, vous pouvez initialiser le paramètre de configuration max_files_per_process de PostgreSQL™ pour limiter la consommation de fichiers ouverts.

Dans Linux 2.4 et suivants, le comportement par défaut de la mémoire virtuelle n'est pas optimal pour PostgreSQL™. Du fait de l'implémentation du « memory overcommit » par le noyau, celui-ci peut arrêter le serveur PostgreSQL™ (le processus serveur maître, « postmaster ») si les demandes de mémoire de PostgreSQL™ ou d'un autre processus provoque un manque de mémoire virtuelle au niveau du système.

Si cela se produit, un message du noyau qui ressemble à ceci (consulter la documentation et la configuration du système pour savoir où chercher un tel message) :

Out of Memory: Killed process 12345 (postgres)

peut survenir. Ceci indique que le processus postgres a été terminé à cause d'un problème de mémoire. Bien que les connexions en cours continuent de fonctionner normalement, aucune nouvelle connexion n'est acceptée. Pour revenir à un état normal, PostgreSQL™ doit être relancé.

Une façon d'éviter ce problème revient à lancer PostgreSQL™ sur une machine où vous pouvez vous assurer que les autres processus ne mettront pas la machine en manque de mémoire. S'il y a peu de mémoire, augmenter la swap peut aider à éviter le problème car un système peut tuer des processus lorsque la mémoire physique et la mémoire swap sont utilisées entièrement.

Si PostgreSQL™ lui-même est la cause d'un manque de mémoire du système, vous pouvez éviter le problème en modifiant votre configuration. Dans certains cas, baisser les paramètres de configuration de la mémoire peut aider, tout particulièrement shared_buffers et work_mem. Dans d'autres cas, le problème peut être causé par l'autorisation d'un trop grand nombre de connexions au serveur de bases de données. Dans beaucoup de cas, il est préférable de réduire max_connections et d'utiliser à la place un logiciel de multiplexage de connexions (connection pooling).

Sur Linux 2.6 et ultérieur, il est possible de modifier le comportement du noyau avec le « overcommit memory ». Bien que ce paramétrage n'empêchera pas ce comportement, il réduira sa fréquence de façon significative et contribuera du coup à un système plus robuste. Ceci se fait en sélectionnant le mode strict de l'overcommit via sysctl :

sysctl -w vm.overcommit_memory=2

ou en plaçant une entrée équivalente dans /etc/sysctl.conf. Vous pourriez souhaiter modifier le paramétrage relatif vm.overcommit_ratio. Pour les détails, voir la documentation du noyau (https://www.kernel.org/doc/Documentation/vm/overcommit-accounting).

Une autre approche, qui peut aussi utiliser la modification de vm.overcommit_memory, est de configurer la valeur de la variable d'ajustement du score OOM, valeur par processus, pour le processus postmaster à -1000, garantissant ainsi qu'il ne sera pas la cible de OOM. La façon la plus simple de le faire est d'exécuter

echo -1000 > /proc/self/oom_score_adj
   

dans le script de démarrage de postmaster juste avant d'appeler postmaster. Notez que cette action doit être faite en tant qu'utilisateur root. Dans le cas contraire, elle n'aura aucun effet. Du coup, un script de démarrage, exécuté par root, est le meilleur endroit où placer ce code. Si vous le faites, vous devriez aussi configurer ces variables d'environnement dans le script de démarrage avant d'invoquer le processus postmaster :

export PG_OOM_ADJUST_FILE=/proc/self/oom_score_adj
export PG_OOM_ADJUST_VALUE=0
   

Ces paramètres vont faire en sorte que les processus fils du postmaster s'exécuteront avec l'ajustement de score OOm normal (0), pour que l'OOM puisse encore les cibler si cela s'avère nécessaire. Vous pouvez utiliser d'autres valeurs pour PG_OOM_ADJUST_VALUE si vous voulez que les processus fils s'exécutent avec un autre ajustement de score. (PG_OOM_ADJUST_VALUE peut aussi être omis, auquel cas sa valeur par défaut est zéro.) Si vous ne voulez pas configurer PG_OOM_ADJUST_FILE, les processus fils s'exécuteront avec le même ajustement de score OOM que le processus père postmaster, ce qui n'est pas conseillé car le but est de s'assurer que le processus postmaster soit protégé par la configuration.

Les anciens noyaux Linux ne proposent pas /proc/self/oom_score_adj, mais peuvent avoir une ancienne version de la même fonctionnalité, nommé /proc/self/oom_adj. Cela fonctionne de façon identique sauf que la valeur de désactivation est -17, et non pas -1000.

L'utilisation des « huge pages » réduit la surcharge lors de l'utilisation de gros morceaux contigus de mémoire, comme ce que fait PostgreSQL™, tout particulièrement lors de l'utilisation de grosses valeurs pour shared_buffers. Pour activer cette fonctionnalité avec PostgreSQL™, vous avez besoin d'un noyau compilé avec CONFIG_HUGETLBFS=y et CONFIG_HUGETLB_PAGE=y. Vous devez aussi configurer le paramètre noyau vm.nr_hugepages. Pour estimer le nombre nécessaire de « huge pages », lancer PostgreSQL™ sans activer les « huge pages » et vérifier la valeur de VmPeak pour le processus postmaster, ainsi que la taille des « huge pages » pour le système en utilisant le système de fichiers /proc. Cela pourrait ressembler à ceci :

$ head -1 $PGDATA/postmaster.pid
4170
$ grep ^VmPeak /proc/4170/status
VmPeak:  6490428 kB
$ grep ^Hugepagesize /proc/meminfo
Hugepagesize:       2048 kB
   

6490428 / 2048 donne approximativement 3169.154. Donc, dans cet exemple, nous avons besoin d'au moins 3170 « huge pages », ce que nous pouvons configurer avec :

$ sysctl -w vm.nr_hugepages=3170
   

Une configuration plus importante serait appropriée si les autres programmes du serveur avaient aussi besoin de « huge pages ». N'oubliez pas d'ajouter cette configuration à /etc/sysctl.conf pour qu'elle soit appliquée à chaque redémarrage.

Parfois, le noyau n'est pas capable d'allouer immédiatement le nombre souhaité de « huge pages », donc il peut être nécessaire de répéter cette commande ou de redémarrer. (Tout de suite après un redémarrage, la plupart de la mémoire de la machine doit être disponible à une conversion en « huge pages ».) Pour vérifier la situation au niveau de l'allocation des « huge pages », utilisez :

$ grep Huge /proc/meminfo
   

Il pourrait être nécessaire de donner le droit à l'utilisateur du système d'exploitation du serveur de bases de données en configurant vm.hugetlb_shm_group via sysctl, et/ou en donnant le droit de verrouiller la mémoire avec ulimit -l.

Il est aussi nécessaire de donner le droit d'utiliser les « huge pages » à l'utilisateur système qui exécute PostgreSQL. Cela se fait en configurant vm.hugetlb_shm_group via sysctl, et le droit de verrouiller la mémoire avec ulimit -l.

Le comportement par défaut pour les « huge pages » dans PostgreSQL™ est de les utiliser quand cela est possible et de revenir aux pages normales dans le cas contraire. Pour forcer l'utilisation des « huge pages », vous pouvez configurer huge_pages à on dans le fichier postgresql.conf. Notez que, avec ce paramètre configuré ainsi, PostgreSQL™ refusera de démarrer s'il ne peut pas récupérer suffisamment de « huge pages ».

Pour une description détaillée des « huge pages » sous Linux™, lisez https://www.kernel.org/doc/Documentation/vm/hugetlbpage.txt.