Quand Thanatos tue Hypnos...
Dans cet article sur le traqueur, nous avions observé que le cluster PostgreSQL plantait complètement suite à loptimisation ratée dun traitement. Linux dispose dun mécanisme permettant déviter le crash complet du serveur si la mémoire vient à manquer. Un mécanisme, OOM Killer, fait le ménage, tue des process et libère des ressources. Le problème est que ce tueur peut sen prendre au process principal de PostgreSQL et provoquer un plantage généralisé.
Démonstration avec Debian Stretch et PostgreSQL 9.6 :
Protection contre la mort, abjuration, niveau 4
Le process de la session folle a été tué mais notre session qui dormait tranquillement a été terminée également. En fait, tout le serveur PostgreSQL est tombé !
La documentation PostgreSQL explique comment modifier la configuration de Linux pour limiter ce comportement. Il sagit dêtre plus conservateur dans lallocation de la mémoire. Démonstration :
Le process fou na pas obtenu la mémoire quil demandait et la transaction a été annulée. Le process qui dormait tranquillement na cette fois rien remarqué et, de manière générale, le serveur PostgreSQL nest pas tombé. Vous pouvez si vous le souhaitez rendre permanente cette configuration en renseignant /etc/sysctl.conf par exemple.
Positionner vm.overcommit_memory=2 et vm.overcommit_ratio=90 signifie quil nest pas possible de surallouer de la mémoire, en loccurence dallouer plus de SWAP + (RAM X 0,9). Le paramétrage par défaut de Linux nest cependant pas à remettre en cause, il convient dans la plupart des cas. Cette précaution nest utile que si tous les process du serveur ne sont pas sous contrôle, ce qui peut être le cas sur un serveur hybride transactionnel et décisionnel. PostgreSQL propose toutefois dautres options dans ce cas, notamment reporter la charger décisionnelle sur une Hot Standby, une base de secours en réplication ET en lecture seule. Cette fonctionnalité est équivalente à loption Active Dataguard dOracle Database Enterprise Edition.