Contention spinlock sur PostgreSQL 16 et Huge Pages

Posté par jacques-bertrand le 12/03/2026
RÉSOLU

jacques-bertrand

Membre depuis le 28/02/2020

actif

salut. on a migre une grosse db sur du pg16 recemment. on a 512gb de ram et on a mis les shared buffers a 128gb

le probleme cest que des quon monte en connections on a un cpu system qui explose alors que les requetes font rien de special. jai limpression que le kernel passe son temps a lock de la memoire

Commentaires

guy63

Membre depuis le 17/03/2025

classique. t'as verifie l'etat des transparent huge pages. si cest sur always ton kernel essaie de defragger la ram en permanence pendant que postgres essaie d'y acceder

therese42

Membre depuis le 19/09/2019

actif

envoie un perf top pour voir quel syscall bouffe le cpu. si tu vois du raw spin lock cest probablement de la contention numa ou des pages memoire

jacques-bertrand

Membre depuis le 28/02/2020

actif

perf top donne ca

45.20% [kernel] [k] _raw_spin_lock
12.10% [kernel] [k] get_page_from_freelist
08.05% postgres [.] s_lock

thp est bien sur always. je devrais le passer a madvise ou le cut direct

guy63

Membre depuis le 17/03/2025

direct a never. postgres sait pas gerer thp correctement sur des shared buffers aussi gros. ca cree des stalls de fou sur le kernel

echo never > /sys/kernel/mm/transparent_hugepage/enabled

therese42

Membre depuis le 19/09/2019

actif

une fois que cest fait faut passer en static huge pages. avec 128gb de buffers t'as trop de page tables le cpu sature le cache tlb

jacques-bertrand

Membre depuis le 28/02/2020

actif

jai coupe thp mais jai encore des pics. pour les static huge pages faut que je calcule le nombre exact de pages de 2mb cest ca

guy63

Membre depuis le 17/03/2025

ouais. tu divises tes 128gb par 2mb et t'ajoutes une marge pour les process de background

sysctl -w vm.nr_hugepages=66000

therese42

Membre depuis le 19/09/2019

actif

oublie pas de configurer postgres apres. faut mettre huge_pages a on sinon il va continuer a utiliser des pages de 4kb standard et ca changera rien

jacques-bertrand

Membre depuis le 28/02/2020

actif

jai tente de reserver les pages mais ca fail. le kernel veut pas me donner les 66000 pages

guy63

Membre depuis le 17/03/2025

cest parce que ta ram est deja fragmentee. faut reboot ou essayer de vider le cache avant de reserver

sync
echo 3 > /proc/sys/vm/drop_caches

therese42

Membre depuis le 19/09/2019

actif

si ta machine a deux sockets verifie aussi ta politique numa. si postgres essaie de chopper des huge pages sur le mauvais node ca va ramer sec

jacques-bertrand

Membre depuis le 28/02/2020

actif

le drop caches a permis de reserver les pages. jai reboot postgres avec la conf. le cpu system est descendu a 5 pourcent

02.10% [kernel] [k] _raw_spin_lock
01.50% postgres [.] s_lock

cest le jour et la nuit les perfs ont triple

guy63

Membre depuis le 17/03/2025

incroyable comment thp peut flinguer une prod. verifie quand meme tes limites memlock dans limits conf pour pas que ca saute au prochain reboot

therese42

Membre depuis le 19/09/2019

actif

bien joue. check aussi le parametre huge page size au cas ou t'aurais des pages de 1gb dispo sur ton cpu cest encore plus efficace

jacques-bertrand

Membre depuis le 28/02/2020

actif

je reste sur 2mb pour linstant cest deja parfait. les spinlocks ont disparu des radars. merci pour le coup de main sur thp

Laisser une réponse

Vous devez être connecté pour poster un message !

Rejoindre la communauté

Recevoir les derniers articles gratuitement en créant un compte !

S'inscrire