18 commentaires
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 0C'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 neverTu 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_blockLe 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/meminfoJ'ai alloué 5000 pages (soit environ 10GB pour mes 8GB de shared_buffers).
sysctl -w vm.nr_hugepages=5000Maintenant, 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 = onRedé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=neverTop. 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.
Laisser une réponse
Vous devez être connecté pour poster un message !
Salut la file. On a migré nos instances PostgreSQL 15 sur des nouveaux noeuds sous Ubuntu 22.04 avec un kernel 6.2 et on se tape des pics de latence monstrueux de manière totalement aléatoire.
Le truc bizarre, c'est que le CPU grimpe en flèche mais c'est du sys CPU, pas du user. Les disques NVMe s'ennuient, les IOPS sont stables, mais le kernel semble s'asphyxier tout seul pendant 5 à 10 secondes.
J'ai vérifié les locks au niveau DB, rien à signaler. Quelqu'un a déjà vu ça sur les kernels récents ?