Pour minimiser les manques de cache dans PostgreSQL ?

Question

Vous pouvez calculer les échecs de cache comme décrit ici.
Cependant, je souhaite savoir comment minimiser le phénomène dans PostgreSQL 9.4.3 sur x86_64-unknown-linux-gnu, compilé par gcc (Debian 4.9.2-10) 4.9.2, 64 bits.J'ai des algorithmes basés sur des tables de hachage, qui provoquent de nombreux échecs de cache en raison d'accès aléatoires.Je suis intéressé par la façon dont vous pouvez minimiser les échecs de cache dans PostgreSQL.

Comment pouvez-vous minimiser les échecs de cache dans PostgreSQL dès la conception ?

Answer 1

Garder les éléments en cache avec PostgreSQL est un équilibre entre ce que vous pouvez avoir dans shared_buffers et ce que vous avez dans le cache du système de fichiers, et en évitant que les deux ne soient expulsés par d'autres processus.

L'une des premières choses que vous pouvez faire sur PostgreSQL 9.4 est de définir huge_pages=on dans ton postgresql.conf.

Cela implique également d'effectuer certaines modifications du système d'exploitation pour permettre à PostgreSQL de démarrer avec cette option activée.La variable sysctl appropriée est vm.nr_hugepages

Vous pouvez faire un calcul rapide et sale de ce que vous devez définir vm.nr_hugepages avec le peu de script shell suivant.

echo $(grep ^VmPeak /proc/$(cat /var/run/postgresql/9.4-main.pid)/status | sed -e 's/VmPeak://' | sed -e 's/kB//' | sed -e 's/[ \t]//g')/$(grep Hugepagesize /proc/meminfo | sed -e 's/Hugepagesize://' | sed -e 's/kB//' | sed -e 's/[ \t]//g') | bc -l | awk '{print int($1+1)}'

Cette ligne récupère le VmPeak du processus PostgreSQL en cours d'exécution dans /proc/$pid/status, qui vous indique la taille maximale de la mémoire virtuelle pour le processus PostgreSQL.Ce nombre est en Ko.Il nettoie l'espacement et la sortie supplémentaire, puis obtient la mesure de Hugepagesize depuis /proc/memstat (qui dans mon cas était de 2048 Ko), effectue ensuite la division appropriée, arrondit la sortie à l'entier le plus proche, puis en ajoute un pour une marge de sécurité.

Dans mon cas, c'était 2147.

Rendez-le permanent en procédant comme suit :

echo "vm.nr_hugepages=2147" >>/etc/sysctl.d/postgresql.conf

Ceci est important pour les raisons suivantes, extraites de la documentation :

/ proc / sys / vm / nr_hugepages indique le nombre actuel d'énormes pages "persistantes" dans l'énorme pool de pages du noyau.Des pages énormes "persistantes" seront renvoyées dans l'énorme pool de pages lorsqu'ils sont libérés par une tâche.Un utilisateur avec des privilèges racine peut allouer dynamiquement plus ou libérer des pages énormes persistantes en augmentant ou en diminuant la valeur de «nr_hugepages».

Les pages utilisées comme pages énormes sont réservées à l'intérieur du noyau et ne peuvent pas être utilisées à d'autres fins.D'énormes pages ne peuvent pas être échangées sous pression de mémoire.

Ainsi, les pages récupérées par le processus postgres pour shared_buffers ne seront pas échangées sous la pression de la mémoire.Et vous aurez également moins de stress sur le TLB pour votre processeur.

Ensuite, nous ajustons OOMKiller, car quelque chose qui tue au hasard des processus postgres n'est pas un bon citoyen.Ces paramètres l'encouragent fortement à ne pas se déclencher.

echo "vm.overcommit_memory=2" >>/etc/sysctl.d/postgresql.conf

echo "vm.overcommit_ratio=100" >>/etc/sysctl.d/postgresql.conf

Ensuite, nous définissons quelques systèmes de planification du noyau :

echo "kernel.sched_autogroup_enabled=0" >>/etc/sysctl.d/postgresql.conf

echo "kernel.sched_migration_cost=5000000" >>/etc/sysctl.d/postgresql.conf

Le coût de migration correspond à la durée totale pendant laquelle le planificateur considérera un processus migré comme étant « chaud en cache » et donc moins susceptible d'être migré à nouveau.

Le groupe automatique activé regroupe essentiellement les tâches par setsid() afin que la réactivité perçue soit améliorée.Mais sur les systèmes serveur, les grands démons comme PostgreSQL vont être lancés à partir du même setsid() et seront effectivement étouffés par les cycles CPU au profit de tâches moins importantes.

Après cela, nous pouvons ajuster le swappiness, qui est un bouton qui contrôle le degré auquel un système permute les processus hors de la mémoire physique.Un nombre plus élevé effectue un échange plus agressif, et un nombre inférieur conserve les éléments dans le cache du système de fichiers plus longtemps.Définir cette valeur sur zéro augmentera les risques de destruction du MOO sous la pression de la mémoire et des E/S.

echo "vm.swappiness=10" >>/etc/sysctl.d/postgresql.conf

Ceux-ci contrôlent la fréquence à laquelle les données sales sont synchronisées sur le disque à partir du cache du système de fichiers.Étant donné que les objets sales dans le cache de pages ne peuvent pas être libérés, une réécriture plus agressive peut garder plus de pages disponibles et éviter de grandes rafales d'E/S disque.

echo "vm.dirty_ratio=2" >>/etc/sysctl.d/postgresql.conf

echo "vm.dirty_background_ratio=1" >>/etc/sysctl.d/postgresql.conf

Puisque la sortie de votre version PostgreSQL affiche GCC 4.9, je suppose que vous utilisez Debian Jessie ou un dérivé, donc le noyau 3.16 évitera certains problèmes d'E/S vraiment terribles que le noyau 3.2 avait, donc c'est certainement une bonne nouvelle.

Une fois que vous avez ajusté tous ces paramètres, redémarrez le système.Cela permettra de garantir que les pages géantes ne sont pas fragmentées lors de leur allocation.Le moyen le meilleur et le plus fiable est de mettre hugepages=2147 (le numéro dont j'avais besoin sur mon serveur), en /etc/default/grub sous GRUB_CMDLINE_LINUX, et courir update-grub, puis redémarrez.Mais je testerais la nécessité de cela, car il est beaucoup plus difficile à changer que le sysctl.

Ceux-ci devraient vous donner un nombre raisonnable de pages dans le cache du système de fichiers et dans shared_buffers.Après cela, en vous assurant que le moins de processus en cours d'exécution sur votre serveur (car ils sont tous en concurrence pour les ressources), devrait vous donner une grande partie de la minimisation des erreurs de cache de pages que vous recherchez.

Des lectures complémentaires sur des pages énormes et leurs effets sont dans le documentation énormetlbpage.

Les paramètres vm et leurs effets sont dans le documentation de la machine virtuelle.

Il s'agit d'un traitement très accessible du système de mémoire Linux Comprendre et optimiser l'utilisation de la mémoire

La documentation PostgreSQL détaille les effets des pages volumineuses en bas de l'écran. page des ressources du noyau

J'espère que cela pourra aider.=)