16.5. Gérer les ressources du noyau

Une installation importante de PostgreSQL peut rapidement épuiser les limites des ressources du système d'exploitation. (Sur certains systèmes, les valeurs par défaut sont trop basses que vous n'avez même pas besoin d'une installation << importante >>.) Si vous avez rencontré ce type de problème, continuez votre lecture.

16.5.1. Mémoire partagée et sémaphore

La mémoire partagée et les sémaphores sont nommés collectivement << IPCSystem V >> (ensemble avec les queues de messages, qui n'ont pas d'importance pour PostgreSQL). Pratiquement tous les systèmes d'exploitation modernes fournissent ces fonctionnalités mais parmi elles toutes ne sont pas activées ou dimensionnées suffisamment par défaut, spécialement les systèmes ayant l'héritage BSD. (Pour les ports QNX et BeOS, PostgreSQL fournit sa propre implémentation de remplacement de ces fonctionnalités.)

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.

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 16.3.1). Les paramètres adéquats du noyau sont nommés de façon cohérente parmi les différents systèmes ; le Tableau 16-2 donne un aperçu. Néanmoins, les méthodes pour les obtenir varient. Les suggestions pour quelques plateformes sont données ci-dessous. Attention, il est souvent nécessaire de redémarrer votre machine, voire même de recompiler le noyau, pour changer ces paramétrages.

Tableau 16-2. Paramètres System V IPC

NameDescriptionValeurs raisonnables
SHMMAXTaille maximum du segment de mémoire partagée (octets)250 Ko + 8.2 Ko * shared_buffers + 14.2 Ko * max_connections jusqu'à l'infini
SHMMINTaille minimum du segment de mémoire partagée (octets)1
SHMALLTotal de la mémoire partagée disponible (octets ou pages)Si octets, identique à SHMMAX ; si pages, ceil(SHMMAX/PAGE_SIZE)
SHMSEGNombre maximum de segments de mémoire partagée par processusSeul un segment est nécessaire mais la valeur par défaut est bien plus importante
SHMMNINombre maximum de segments de mémoire partagée pour tout le systèmeComme SHMSEG plus la place pour les autres applications
SEMMNINombre maximum d'identifiants de sémaphores (c'est-à-dire d'ensembles)Au moins ceil(max_connections / 16)
SEMMNSNombre maximum de sémaphores rapartis dans le systèmeceil(max_connections / 16) * 17 plus la place pour les autres applications
SEMMSLNombre maximum de sémaphores par ensembleau moins 17
SEMMAPNombre d'entrées dans la carte des sémaphoresvoir le texte
SEMVMXValeur maximum d'une sémaphoreau moins 1000 (vaut souvent par défaut 32767, ne pas changer sauf si cela vous est demandé.)

Le paramètre de mémoire partagé le plus important est SHMMAX, la taille maximum, en octets, d'un segment de mémoire partagée. Si vous obtenez un message d'erreur à partir de shmget comme Invalid argument, il est possible que cette limite soit dépassée. La taille du segment de mémoire partagée requise varie à la fois avec le nombre de tampons requis (option -B) et le nombre de connexions autorisées (option -N), bien que le premier soir le plus important. (Vous pouvez, en solution temporaire, baisser ces paramétrages pour supprimer l'échec.) En tant qu'approximation brute, vous pouvez estimer la taille de segment requise en multipliant le nombre de tampons et la taille d'un bloc (8 Ko par défaut) plus un ajout ample (au moins la moitié d'1 Mo). Tout message d'erreur que vous obtenez contiendra la taille de la requête d'allocation échouée.

Moins sensible aux problèmes est la taille minimum des segments de mémoire partagée (SHMMIN), qui devrait être au plus à environ 256 Ko pour PostgreSQL (il est habituellement à 1). Le nombre maximum de segments au travers du système (SHMMNI) ou par processus (SHMSEG) ne devrait pas poser problème sauf si votre système les a initialisé à zéro. Certains systèmes ont aussi une limite sur le nombre total de mémoire partagée dans le système ; voir les instructions spécifiques à la plateforme ci-dessous.

PostgreSQL utilise une sémaphore par connexion autorisée (option -N), par ensemble de 16. Chacun de ces ensembles contiendra aussi une 17è sémaphore qui contient un << nombre magique >>, pour détecter la collision avec des ensembles de sémaphore utilisé 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 un extra de chacune des 16 connexions autorisées (voir la formule dans Tableau 16-2). 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 / 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. Ce paramètre définit la taille de la carte de ressources de sémaphores, dans laquelle chaque bloc contigu de sémaphores disponibles ont besoin d'une entrée. Lorsqu'un ensemble de sémaphore 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ées sont perdues (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, ne concernent pas PostgreSQL.

BSD/OS

Mémoire partagée. Par défaut, seulement 4 Mo de mémoire partagée est supportée. Gardez en tête que la mémoire partagée n'est pas paginable ; elle est verrouillée en RAM. Pour accroître la mémoire partagée supportée par votre système, ajoutez ce qui suit à la configuration de votre noyau. Une valeur de 1024 pour SHMALL représente 4 Mo de mémoire partagée Ce qui suit augmente l'aire de mémoire partagée jusqu'à 32 Mo :

options "SHMALL=8192"
options "SHMMAX=\(SHMALL*PAGE_SIZE\)"

Pour ceux utilisant une version 4.3 ou ultérieure, vous aurez probablement besoin d'augmenter KERNEL_VIRTUAL_MB au-dessus de la valeur par défaut, 248. Une fois tous les changements effectués, recompilez le noyau et redémarrez.

Pour ceux utilisant une version 4.0 ou antérieures, utilisez bpatch pour connaître la valeur sysptsize dans le noyau actuel. Elle est calculée dynamiquement au démarrage.

$ bpatch -r sysptsize
0x9 = 9

Ensuite, ajoutez SYSPTSIZE comme valeur codée en dur dans le fichier de configuration du noyau. Augmentez la valeur que vous trouvez en utilisant bpatch. Ajoutez 1 pour chaque 4 Mo supplémentaire de mémoire partagée que vous souhaitez.

options "SYSPTSIZE=16"

sysptsize ne peut pas être modifié avec sysctl.

Sémaphores. Vous pourriez avoir besoin d'augmenter le nombre de sémaphores. Par défaut, PostgreSQL alloue 34 sémaphores, qui est à moitié au-dessus du total système par défaut, 60. Initialisez les valeurs que vous souhaitez dans le fichier de configuration du noyau :

options "SEMMNI=40"
options "SEMMNS=240"

FreeBSD
NetBSD
OpenBSD

Les options SYSVSHM et SYSVSEM doivent être activées à la compilation du noyau. (Ils le sont par défaut.) La taille maximum de mémoire partagée est déterminée par l'option SHMMAXPGS (en pages). Ce qui suit montre un exemple de l'initialisation des différents paramètres :

options         SYSVSHM
options         SHMMAXPGS=4096
options         SHMSEG=256

options         SYSVSEM
options         SEMMNI=256
options         SEMMNS=512
options         SEMMNU=256
options         SEMMAP=256

(Sur NetBSD et OpenBSD, le mot clé est en fait option au singulier.)

Vous pourriez aussi vouloir configurer votre noyau pour verrouiller la mémoire partagée en RAM et l'empêcher d'être paginée en swap. Utilisez le paramétrage kern.ipc.shm_use_phys de sysctl.

HP-UX

Les paramètres par défaut tendent à suffire pour des installations normales. Sur HP-UX 10, la valeur par défaut de SEMMNS est 128, qui pourrait être trop basse pour de gros sites de bases de données.

Les paramètres IPC peuvent être initialisés dans System Administration Manager (SAM) sous Kernel Configuration->Configurable Parameters. Allez sur Create A New Kernel une fois terminée.

Linux

La limite de mémoire partagée par défaut (à la fois SHMMAX et SHMALL) est de 32 Mo pour les noyaux 2.2 mais cela peut se changer dans le système de fichiers proc (sans redémarrage). Par exemple, pour permettre 128 Mo :

$ echo 134217728 >/proc/sys/kernel/shmall
$ echo 134217728 >/proc/sys/kernel/shmmax

Vous pouvez placer ces commandes dans un script exécuté au démarrage.

Autrement, vous pouvez utiliser sysctl, si cette commande est disponible, pour contrôler ces paramètres. Cherchez un fichier nommé /etc/sysctl.conf et ajoutez les lignes qui suivent :

kernel.shmall = 134217728
kernel.shmmax = 134217728

Ce fichier est habituellement traité au démarrage mais sysctl peut aussi être appelé explicitement plus tard.

D'autres paramètres ont une taille suffisante pour toute application. Si vous voulez voir par vous-même, jetez un œil dans /usr/src/linux/include/asm-xxx/shmparam.h et /usr/src/linux/include/linux/sem.h.

MacOS X

Avec OS X 10.2 et antérieures, éditez le fichier /System/Library/StartupItems/SystemTuning/SystemTuning et modifiez les valeurs avec les commandes suivantes :

sysctl -w kern.sysv.shmmax
sysctl -w kern.sysv.shmmin
sysctl -w kern.sysv.shmmni
sysctl -w kern.sysv.shmseg
sysctl -w kern.sysv.shmall

Avec OS X 10.3, ces commandes ont été déplacées dans /etc/rc et doivent être éditées là-bas.

SCO OpenServer

Dans la configuration par défaut, seuls 512 Ko de mémoire partagée par segment est autorisé, ce qui est assez pour -B 24 -N 12. Pour augmenter ce paramétrage, allez tout d'abord dans le répertoire /etc/conf/cf.d. Pour afficher la valeur courante de SHMMAX, lancez

./configure -y SHMMAX

Pour configurer une nouvelle valeur de SHMMAX, lancez

./configure SHMMAX=valeur

value est la nouvelle valeur que vous voulez utiliser (en octets). Après avoir configuré SHMMAX, reconstruisez le noyau :

./link_unix

et redémarrez.

Solaris

Au moins dans la version 2.6, la taille maximum par défaut des segments de mémoire partagée est trop basse pour PostgreSQL. Le paramétrage adéquat peut être modifié dans /etc/system, par exemple :

set shmsys:shminfo_shmmax=0x2000000
set shmsys:shminfo_shmmin=1
set shmsys:shminfo_shmmni=256
set shmsys:shminfo_shmseg=256

set semsys:seminfo_semmap=256
set semsys:seminfo_semmni=512
set semsys:seminfo_semmns=512
set semsys:seminfo_semmsl=32

Vous avez besoin de redémarrer pour que les modifications prennent effet.

Voir aussi http://sunsite.uakom.sk/sunworldonline/swol-09-1997/swol-09-insidesolaris.html pour des informations sur la mémoire partagée sous Solaris.

UnixWare

Avec UnixWare 7, la taille maximum des segments de mémoire partagée est de 512 Ko dans la configuration par défaut. Ceci est suffisant pour -B 24 -N 12. Pour afficher la valeur courante de SHMMAX, lancez

/etc/conf/bin/idtune -g SHMMAX

qui affiche la valeur courante, par défaut, minimum et maximum. Pour configurer une nouvelle valeur de SHMMAX, lancez

/etc/conf/bin/idtune SHMMAX valeur

valeur est la nouvelle valeur que vous voulez utiliser (en octets). Après avoir initialisé SHMMAX, reconstruisez le noyau :

/etc/conf/bin/idbuild -B

et relancez.

16.5.2. Limites de ressources

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é 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.

16.5.3. Linux Memory Overcommit

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 d'un autre processus provoque un manque de mémoire virtuelle au niveau du système.

Si ceci arrive, vous verrez un message du noyau qui ressemble à ceci (consultez la documentation et la configuration de votre système pour savoir où chercher un tel message) :

Out of Memory: Killed process 12345 (postmaster). 

Ceci indique que le processus postmaster a été terminé à cause d'un problème de mémoire. Bien que les connexions en cours continueront de fonctionner normalement, aucune nouvelle connexion ne sera acceptée. Pour revenir à un état normal, PostgreSQL devra ê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.

Sur Linux 2.6 et ultérieure, une meilleure solution est de modifier le comportement du noyau de façon à ce qu'il n'<< overcommit >> pas la mémoire. Ceci se fait en sélectionnant le mode overcommit strict 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 (Documentation/vm/overcommit-accounting).

Quelques noyaux 2.4 de vendeurs ont des pré-versions de l'overcommit du 2.6. Néanmoins, configurer vm.overcommit_memory à 2 sur un noyau qui n'a pas le code correspondant rendra les choses pires qu'elles n'étaient. Il est recommandé d'inspecter le code source du noyau (voir la fonction vm_enough_memory dans le fichier mm/mmap.c) pour vérifier ce qui est supporté dans votre copie avant d'essayer ceci avec une installation 2.4. La présence du fichier de documentation overcommit-accounting ne devrait pas être pris comme une preuve de la présence de cette fonctionnalité. En cas de doute, consultez un expert du noyau ou le vendeur de votre noyau.