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
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
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
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
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
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
ouais. tu divises tes 128gb par 2mb et t'ajoutes une marge pour les process de background
sysctl -w vm.nr_hugepages=66000
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
jai tente de reserver les pages mais ca fail. le kernel veut pas me donner les 66000 pages
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
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
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
incroyable comment thp peut flinguer une prod. verifie quand meme tes limites memlock dans limits conf pour pas que ca saute au prochain reboot
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
je reste sur 2mb pour linstant cest deja parfait. les spinlocks ont disparu des radars. merci pour le coup de main sur thp
Vous devez être connecté pour poster un message !
Recevoir les derniers articles gratuitement en créant un compte !
S'inscrire
jacques-bertrand
Membre depuis le 28/02/2020actif
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