Latence PostgreSQL erratique et pics de CPU sys sur Kernel 6.2

Salut. Si tu as du sys CPU élevé sans IOPS délirantes, c'est souvent le kernel qui galère sur la gestion de la mémoire.

Est-ce que tu as jeté un oeil aux stats de la mémoire ? Un petit `vmstat 1` pendant le pic nous aiderait à voir si ça swappe ou si le kernel fait autre chose.

J'ai réussi à choper un pic avec `vmstat`. Pas de swap, mais la colonne sy explose et j'ai énormément de context switches.

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
12  0      0 456721 123412 8901234    0    0     0     0 4512 89234 10 75 15  0  0

C'est n'importe quoi ce volume de cs pour une charge de lecture basique.

C'est typiquement un problème de Transparent Huge Pages (THP). Sur les kernels récents, le daemon khugepaged est parfois trop agressif pour essayer de défragmenter la RAM.

Check l'état actuel de ta config THP via `/sys/kernel/mm/transparent_hugepage/enabled`.

Effectivement, je suis en always par défaut :

cat /sys/kernel/mm/transparent_hugepage/enabled
[always] madvise never

Tu penses que c'est le mécanisme de compaction qui met PostgreSQL en PLS ?

C'est presque certain. PostgreSQL utilise son propre buffer cache et quand le kernel tente de réorganiser des pages de 4k en pages de 2M en arrière-plan, il pose des locks sur les pages mémoire.

Si tu veux en avoir le coeur net, lance un `perf top` quand le CPU sys monte. Si tu vois passer `compact_zone` ou `_raw_spin_lock` en haut de la liste, tu as ton coupable.

Je viens de faire le `perf top` pendant un micro-freeze. C'est flagrant.

  45.23%  [kernel]  [k] _raw_spin_lock
  12.10%  [kernel]  [k] compact_zone
   8.45%  [kernel]  [k] isolate_migratepages_block

Le kernel passe littéralement sa vie à essayer de compacter la mémoire.

Bascule immédiatement en madvise ou never. Pour PostgreSQL, le consensus est souvent de désactiver purement et simplement le THP ou de passer par des Huge Pages statiques (Explicit Huge Pages).

Fais un `echo never > /sys/kernel/mm/transparent_hugepage/enabled` à chaud pour voir si la latence se stabilise.

Testé à l'instant. Les pics de sys CPU ont disparu instantanément. Par contre, j'ai l'impression que mes performances globales en pâtissent un peu.

Comment je configure proprement les Huge Pages statiques pour que PostgreSQL en profite sans subir la compaction du kernel ?

Il faut d'abord que tu calcules combien de pages de 2MB il te faut. Regarde ton `shared_buffers` dans ton `postgresql.conf` et ajoute un peu de marge.

Ensuite, tu configures `vm.nr_hugepages` via `sysctl`.

Oublie pas de vérifier `/proc/meminfo` après avoir appliqué le sysctl pour être sûr que le kernel a bien réussi à allouer les pages contiguës.

grep Huge /proc/meminfo

J'ai alloué 5000 pages (soit environ 10GB pour mes 8GB de shared_buffers).

sysctl -w vm.nr_hugepages=5000

Maintenant, je dois changer quoi côté PostgreSQL ?

Il faut modifier le paramètre `huge_pages` dans ton `postgresql.conf`. Passe-le à on (et pas seulement try, comme ça tu es sûr qu'il démarre uniquement s'il peut les utiliser).

huge_pages = on

Redémarrage effectué. PostgreSQL a bien locké les huge pages statiques.

Je monitoring depuis 20 minutes, le sys CPU est tombé à 1% constant et le débit de transactions est beaucoup plus stable. Plus aucun freeze de 10 secondes.

Parfait. N'oublie pas de rendre la configuration persistante dans `/etc/sysctl.conf` et de vérifier ton scheduler IO tant que tu y es, avec NVMe on conseille souvent `none` ou `mq-deadline`.

C'est noté pour le scheduler. J'ai aussi ajouté la désactivation de THP dans les paramètres de boot du kernel via GRUB pour être tranquille au prochain reboot.

transparent_hugepage=never

Top. C'est un grand classique de la stack Linux moderne : les optimisations génériques (THP) flinguent souvent les workloads hautement spécialisés comme les bases de données.

Exact. Ravi que ça tourne mieux. Surveille quand même si tu n'as pas de OOM killer qui traîne si tu as été trop gourmand sur les huge pages statiques.

La RAM libre est stable, j'ai laissé assez de place pour l'OS et les process annexes. Un grand merci pour le coup de main, c'était vraiment frustrant de voir ces spikes sans comprendre la cause kernel.