Kernel panic sur mmap et corruption de page cache avec PostgreSQL 15

ça sent le bug de driver storage ou une barrette de ram foireuse. poste le panic log complet qui sort de kdump ou de ton serial console

voila le bout de log que j ai pu recup via netconsole

BUG: unable to handle page fault for address: ffff888123456788
RIP: 0010:__free_pages_ok+0x12/0x250
Call Trace:
  free_unref_page_prepare+0x120/0x1a0
  free_unref_page+0x15/0x70
  __put_page+0x32/0x40
  pagecache_get_page+0x120/0x230

le call trace montre clairement que le kernel essaie de liberer une page qui est deja foireuse ou mal mappee dans le page cache. est ce que vous utilisez du zfs ou du xfs

on est sur du xfs avec un raid10 de nvme samsung. le fs a ete créé avec les options par defaut

on a aussi du transparent hugepages activé par defaut sur cette version d ubuntu

desactive thp direct. postgresql et thp ça a toujours fait des trucs bizarres surtout sur les operations de compactage memoire en background

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

je parie sur une race condition entre le mechanisme de copy-on-write de postgres et le kernel. postgres fait des doubles ecritures parfois. vous avez quoi en config de shared_buffers

shared_buffers est a 128gb sur une machine de 512gb. on a configuré 64000 huge pages de 2mb manuellement dans sysctl

ton souci vient peut etre de la fragmentation memoire. si le kernel n arrive plus a allouer de pages contigues pour le page cache a cause des huge pages statiques ça peut paniquer si un driver essaie de faire du dma mal foutu

lance un cat /proc/buddyinfo pour voir l etat de tes zones memoire

resultat de buddyinfo

Node 0, zone Normal 120 54 21 10 5 2 0 0 0 0 0
Node 1, zone Normal 45 32 12 5 2 0 0 0 0 0 0

c est la catastrophe non. les ordres superieurs sont tous a zero

ouais ta memoire est completement fragmentee. le kernel ne peut plus sortir une page de plus de 4kb. ton driver de raid ou de reseau doit paniquer quand il demande un buffer contigu pour ses requetes

augmente le min_free_kbytes pour forcer le kernel a garder de la marge

sysctl -w vm.min_free_kbytes=4194304

et passe ton vm.zone_reclaim_mode a 0 si c est pas deja fait pour eviter que le kernel s excite a essayer de bouger des pages entre les nodes numa en plein milieu d une ecriture disque

j ai appliqué les reglages. j ai aussi remarqué que le firmware des samsung nvme avait une mise a jour pour des problemes de corruption de donnees sur les gros write buffers

j ai flashé le firmware et rebooté les noeuds

le firmware ssd + la fragmentation ram c est le combo gagnant pour un kernel panic. tiens nous au jus si ca replante dans les 24h

ça fait 48h que ça tourne sans aucun crash. les perfs sont plus stables aussi. merci pour l aide sur buddyinfo j avais jamais regardé ce fichier