L'OOM killer ha ammazzato il database: perché, e come si evita?

Quando la memoria finisce davvero, il kernel deve scegliere chi sacrificare, e sceglie con un punteggio (oom_score) che premia... i processi più grossi: il database è la vittima designata per definizione. La conferma: dmesg -T | grep -i oom o journalctl -k raccontano chi è morto e quanto consumava. Le difese, in ordine: 1) capisci chi mangia – spesso non è il DB ma un vicino (backup, applicazione che perde memoria) che spinge tutti nel burrone; 2) proteggi le vittime pregiate: OOMScoreAdjust=-800 nella unit systemd del DB dice al kernel "lui no"; 3) limita i sospetti: MemoryMax= nelle unit (o i limiti dei container) fa morire il colpevole invece dell'innocente; 4) una swap piccola come ammortizzatore (swap usata non è un male) e earlyoom per uccidere prima che il sistema si pianti. E se l'OOM arriva a orari regolari, il riavvio misterioso di stanotte ha appena trovato il suo movente.