PostgreSQL 15 et OOM Killer malgré l'usage de HugePages

Salut. C'est classique avec l'overcommit à 2. Si tu as 512GB de RAM et que tu en bloques déjà 256GB pour les HugePages, ton calcul d'overcommit devient très risqué.

Tu peux nous donner le résultat de `cat /proc/meminfo` et ton `vm.overcommit_ratio` ?

Il faut aussi regarder du côté de la segmentation. Si tes 4000 connexions consomment chacune un peu de RAM pour le `work_mem`, tu satures peut-être la zone hors HugePages.

Poste aussi ton `postgresql.conf` pour qu'on voit les paramètres de mémoire de travail.

Voici le retour de meminfo :

MemTotal: 528394240 kB
MemFree: 21456784 kB
HugePages_Total: 131072
HugePages_Free: 124

Et pour le sysctl :

vm.overcommit_memory = 2
vm.overcommit_ratio = 50

Mon `work_mem` est à 64MB.

Ton ratio est trop bas. Avec `vm.overcommit_memory` à 2, le kernel limite l'allocation à (Swap + RAM * ratio / 100).

Mais attention, le kernel retire la taille des HugePages de ce calcul sur les versions récentes. Tu te retrouves avec une limite virtuelle minuscule pour tes 4000 process.

Exactement. Fais le calcul : 512GB * 0.5 = 256GB. Si tes HugePages occupent déjà 256GB, ta CommitLimit est probablement déjà atteinte avant même de lancer un query.

Regarde la ligne CommitLimit dans `/proc/meminfo`.

Effectivement, je viens de voir ça :

CommitLimit: 264197120 kB
Committed_AS: 261845120 kB

On est à la limite de la rupture. Mais pourquoi ça ne swap pas ? On a 32GB de swap pourtant.

Le mode 2 de overcommit empêche justement l'allocation si elle dépasse la limite, il ne cherche même pas à swapper, il refuse le malloc ou déclenche l'OOM si la pression est trop forte sur les structures kernel.

Essaie de monter `vm.overcommit_ratio` à 80 ou 90 pour voir.

Avant de toucher au ratio, vérifie aussi les Transparent HugePages (THP). Si c'est à always, ça peut causer une fragmentation de la mémoire restante.

cat /sys/kernel/mm/transparent_hugepage/enabled

Le sysfs me dit `[always] madvise never`. C'est donc activé. Tu penses que ça interfère avec mes HugePages statiques ?

Carrément. Le kernel essaie de compacter la mémoire restante pour faire des pages de 2MB en arrière-plan, ça crée des stalls et ça bouffe du CPU. Sur une DB, on met toujours ça à never ou madvise.

Fais un `echo never > /sys/kernel/mm/transparent_hugepage/enabled` pour tester immédiatement.

Et n'oublie pas de vérifier `vm.admin_reserve_kbytes`. Si c'est trop bas, le root ne pourra même pas se logguer pour débugger quand l'OOM va trigger.

J'ai passé le ratio à 85 et désactivé les THP. Le `Committed_AS` semble s'être stabilisé et j'ai plus de marge sur la CommitLimit.

Par contre, j'ai remarqué des pics de `Dirty` memory dans meminfo juste avant les ralentissements. C'est lié au checkpoint ?

Oui, PostgreSQL flush ses buffers. Si ton storage ne suit pas, la Dirty memory monte et le kernel bloque les écritures (dirty_thresh).

Vérifie `vm.dirty_ratio` et `vm.dirty_background_ratio`. On les baisse souvent sur des grosses machines pour lisser les I/O.

Si tu as du NVMe, mets `vm.dirty_background_ratio` à 5 et `vm.dirty_ratio` à 10. Ça forcera le kernel à écrire plus souvent par petits paquets.

Ok, j'ai appliqué les réglages sur l'overcommit et les dirty ratios. On vient de passer le pic de trafic de 14h sans aucun kill et la latence est bien plus stable.

C'était bien ce calcul d'overcommit qui ignorait la place prise par les HugePages qui nous tuait. Merci pour le coup de main !