15 commentaires
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: 124Et pour le sysctl :
vm.overcommit_memory = 2
vm.overcommit_ratio = 50Mon 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.
Effectivement, je viens de voir ça :
CommitLimit: 264197120 kB
Committed_AS: 261845120 kBOn 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.
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.
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.
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 !
Laisser une réponse
Vous devez être connecté pour poster un message !
Salut à tous. Je commence à saturer sur un problème d'OOM Killer qui strike nos instances PostgreSQL 15 en prod. On a des serveurs avec 512GB de RAM, et on a réservé 256GB en HugePages fixes.
Le
shared_buffersest bien calé sur 256GB également. Pourtant, dès qu'on monte à 4000 connexions actives, le kernel décide de kill le process postmaster alors qu'il reste théoriquement de la RAM libre hors HugePages.J'ai vérifié
vm.overcommit_memoryet il est à 2. Quelqu'un a une idée ?