![\"twitter\"](\"https:\/\/blog.capdata.fr\/wp-content\/plugins\/social-media-feather\/synved-social\/image\/social\/regular\/48x48\/twitter.png\" "\\"Share")
<\/a><\/a>![\"linkedin\"](\"https:\/\/blog.capdata.fr\/wp-content\/plugins\/social-media-feather\/synved-social\/image\/social\/regular\/48x48\/linkedin.png\" "\\"Share")
<\/a>![\"mail\"](\"https:\/\/blog.capdata.fr\/wp-content\/plugins\/social-media-feather\/synved-social\/image\/social\/regular\/48x48\/mail.png\" "\\"Share")
<\/a>![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2021\/01\/oom-killer.jpg\")
<\/p>\n
<\/p>\n
Hello,<\/p>\n
bonjour \u00e0 toutes et tous et bonne ann\u00e9e 2021 \u00e0 vous !<\/p>\n
Aujourd’hui nous allons nous pencher sur un nouveau sujet qui parlera \u00e0 beaucoup d’entre nous utilisateurs linux qui administrons des bases de donn\u00e9es sous ce syst\u00e8me !<\/p>\n
Nous avons rencontr\u00e9, r\u00e9cemment chez un de nos clients, des soucis de “kill” de process survenus sur notre instance PostgreSQL. C’est durant des op\u00e9rations assez lourdes en terme de charge m\u00e9moire que cela s’est produit. Notre client utilise l’extension “pg_partman” qui, coupl\u00e9 avec “pg_cron” permet de disposer du partitionning non natif, au sein d’une base PostgreSQL.<\/p>\n
Jusqu’ici tout allait bien, mais avec la charge de donn\u00e9es ins\u00e9r\u00e9es dans les partitions, certaines op\u00e9rations ont pris beaucoup plus de temps, et surtout ont n\u00e9cessit\u00e9 de d’avantage de ressources m\u00e9moire !<\/p>\n
Nous avons remont\u00e9 l’ordre SQL en cause qui \u00e9tait ex\u00e9cut\u00e9 via “pg_partman” :<\/p>\n
select\u00a0result.fn_agreg_rumresulthourly();<\/em><\/p>\n Pour les utilisateurs de cette extension, cela parlera tr\u00e8s certainement, il s’agit d’un job qui va “merger” les donn\u00e9es par heures pour en faire une nouvelle partition journali\u00e8re. Et c’est la que la m\u00e9canique peut vite \u00eatre tr\u00e8s compliqu\u00e9e \u00e0 g\u00e9rer par l’OS en arri\u00e8re plan….<\/p>\n <\/p>\n Lorsqu’un processus requiert de la m\u00e9moire pour son fonctionnement, le kernel Linux va alors lui r\u00e9server des pages qui lui seront n\u00e9cessaire pour mener \u00e0 bien son op\u00e9ration, c’est le principe de la m\u00e9moire r\u00e9serv\u00e9e (reserved memory). Au fur et \u00e0 mesure du cycle de vie du processus, le syst\u00e8me devra lui valider ces pages r\u00e9ellement en m\u00e9moire, afin que celles ci ne soient pas potentiellement r\u00e9utilisables par d’autres processus, ces pages lui sont d\u00e9finitivement attribu\u00e9es en fonction de la RAM disponible (principe de “commited” memory).<\/p>\n Cependant, comment cela se passe si ce m\u00eame processus demande trop de m\u00e9moire et que l’on arrive \u00e0 une saturation RAM ? il y’a alors des cons\u00e9quences pour votre syst\u00e8me Linux. L’OS va devoir proc\u00e9der \u00e0 ce que l’on appelle du “over-commit” !<\/p>\n Mais il faut bien garder \u00e0 l’esprit que cela est un m\u00e9canisme qui reste dans le cadre de l’exceptionnel, et lorsque le processus demande trop de ressources, l’OS ne pourra, \u00e0 un moment, plus y r\u00e9pondre. Le kernel linux doit tout faire pour \u00e9viter un “kernel panic” et par cons\u00e9quence un “crash” du syst\u00e8me global et un reboot du serveur. Ainsi il va se d\u00e9fendre gr\u00e2ce \u00e0 ce “garde-fou” qui lui permettra de conserver la stabilit\u00e9 du syst\u00e8me et surtout supprimer le processus qui demande trop de ressources m\u00e9moire.<\/p>\n La configuration de ce processus se fera dans “sysctl” en configurant les param\u00e8tres suivants :<\/p>\n <\/p>\n Les valeurs possibles pour le param\u00e8tre “vm.overcommit_memory<\/strong>” sont :<\/p>\n 0 – Le syst\u00e8me va tenter d’effectuer de l’over-commit selon un algorithme d\u00e9fini et en fonction des ressources (valeur par d\u00e9faut)<\/em><\/span> Si la valeur 2 est choisie pour “vm.overcommit_memory<\/strong>” alors le param\u00e8tre “vm.overcommit_ratio<\/strong>” rentre en jeu.<\/p>\n Ce dernier param\u00e8tre renseigne sur quel pourcentage de m\u00e9moire l’OS va pouvoir utiliser au maximum pour un processus. Par d\u00e9faut, la valeur est fix\u00e9 \u00e0 50%. Gardons \u00e0 l’esprit que Linux utilisera cette formule pour savoir combien de m\u00e9moire il pourra au plus allouer :<\/p>\n <\/p>\n Il est possible de compl\u00e8tement d\u00e9sactiver OOM-Killer, m\u00eame si cela n’est pas vraiment recommand\u00e9.<\/p>\n Par d\u00e9faut, lorsque “OOM-Killer” se d\u00e9clenche, nous n’avons pas de kernel panic, c’est ce qui est attendu afin de prot\u00e9ger l’OS et les autres processus actifs du serveur. La valeur est bien \u00e0 0. Si tel n’\u00e9tait pas le cas, nous devrions la modifier :<\/p>\n <\/p>\n S’il l’on revient \u00e0 notre cas survenu chez notre client, nous avons l’exemple m\u00eame du comportement li\u00e9 \u00e0 OOM-Killer. Comme on peut le voir, un “kill -9” a \u00e9t\u00e9 effectu\u00e9 sur le process 9725. Aussit\u00f4t le “postmaster” PostgreSQL a ordonn\u00e9 une op\u00e9ration “Rollback” sur la base afin d’assurer l’int\u00e9grit\u00e9 des donn\u00e9es sur celle ci. Durant ce temps, la base n’\u00e9tait pas disponible (FATAL: the database system is in recovery mode).<\/p>\n Nous avons pu remonter les informations dans les traces syst\u00e8mes avec “sar” mais \u00e9galement dans le “\/var\/log\/messages” :<\/p>\n <\/p>\n Le process 9725 avait presque 1,7M de pages r\u00e9serv\u00e9es, mais celui ci a \u00e9t\u00e9 kill\u00e9 car il d\u00e9passait 6,5Go en m\u00e9moire. Le log \u00e9tant assez explicite, nous savons maintenant que c’est la commande SQL “select result.fn_agreg_rumresultdaily()” qui a provoqu\u00e9 cette surconsommation m\u00e9moire.<\/p>\n <\/p>\n <\/p>\n Comme nous le savons, un serveur de bases de donn\u00e9es ne devrait pas swapper, c’est vrai dans la plupart des SGBDR. Cependant, les autres processus du syst\u00e8me ou pr\u00e9sents sur le serveurs peuvent disposer d’un espace de swap afin de consommer d’avantage de m\u00e9moire \u00e0 un instant donn\u00e9. Il est aussi de bonne pratique, pour un serveur base de donn\u00e9es, d’utiliser des pages larges (huges pages) afin de disposer de pages m\u00e9moire les moins fractionn\u00e9es possible. Cette configuration se fera via “sysctl” en d\u00e9finissant\u00a0 les param\u00e8tres “vm.nr_hugepages”. Pour un serveur disposant de 8Go de RAM, on place les pages li\u00e9s au param\u00e8tre “shared_buffers”, soit 2Go. Par cons\u00e9quence, ce sera la commande :<\/p>\n <\/p>\n Enfin l’autre solution si l’on ne met pas en place les “huges pages”, et ce en accord avec la documentation PostgreSQL, c’est de g\u00e9rer manuellement\u00a0 le over-commit sur le serveur en capant le ratio d’utilisation de la RAM pour un processus donn\u00e9.<\/p>\n Comme le mentionne la documentation PostgreSQL sur le site<\/a> ,\u00a0 il est recommand\u00e9 de passer le param\u00e8tre vm.overcommit_memory<\/strong> \u00e0 2<\/strong><\/span>\u00a0:<\/p>\n Il restera alors \u00e0 changer le ratio de m\u00e9moire utilisable au maximum. On pourra d\u00e9finir celui ci \u00e0 75% par exemple.<\/p>\n <\/p>\n S’il l’on reprend la formule Linux pour la limite d’affectation de processus, nous aurons donc :<\/p>\n Limite = 4096 + 8192 (75\/100) – > soit une limite \u00e0 10Go. Le process peut utiliser jusqu’\u00e0 10Go<\/strong> en m\u00e9moire.<\/p>\n <\/p>\n Depuis ces modifications, nous n’avons plus rencontr\u00e9 ce souci avec “OOM-Killer”, le batch de nuit li\u00e9 \u00e0 “pg_partman” se d\u00e9roule correctement.<\/p>\n <\/p>\n N’h\u00e9sitez pas \u00e0 laisser des commentaires.<\/p>\n @+<\/p>\n <\/p>\n Emmanuel RAMI<\/p>\n <\/p>\n Hello, bonjour \u00e0 toutes et tous et bonne ann\u00e9e 2021 \u00e0 vous ! Aujourd’hui nous allons nous pencher sur un nouveau sujet qui parlera \u00e0 beaucoup d’entre nous utilisateurs linux qui administrons des bases de donn\u00e9es sous ce syst\u00e8me… Continuer la lecture OOM-Killer, qu’est ce que c’est ?<\/h4>\n
\nC’est la qu’intervient le process syst\u00e8me “Out-of-memory Killer” ou “OOM-Killer”.<\/p>\nvm.overcommit_memory\r\nvm.overcommit_ratio<\/span><\/pre>\n
\n1 – le syst\u00e8me va effectuer de l’over-commit dans tous les cas, sans v\u00e9rification (\u00e0 vos risques et p\u00e9rils !)<\/em><\/span>
\n2 – Pas d’over-commit, seule la m\u00e9moire r\u00e9ellement allouable sera utilis\u00e9e selon un ratio d\u00e9fini.<\/em><\/span><\/p>\n
\nMais il sera possible de l’augmenter .<\/p>\nLimite allocation m\u00e9moire = Swap + RAM * (Overcommit Ratio \/ 100)<\/span><\/pre>\nsysctl -w vm.oom-kill=0 \r\n<\/span><\/strong>ou bien directement dans le fichier \/etc\/sysctl.conf : echo \"vm.oom-kill=0\" >> \/etc\/sysctl.conf\r\n<\/strong><\/pre>\n
\nPour s’en assurer, nous interrogerons le param\u00e8tre “panic_on_oom” et v\u00e9rifions que la valeur est \u00e0 0 :<\/p>\n[root@VM_client]# cat \/proc\/sys\/vm\/panic_on_oom\r\n0<\/pre>\n
sysctl -w vm.panic_on_oom=0 \r\n<\/span><\/strong>ou bien directement dans le fichier \/etc\/sysctl.conf : echo \"vm.panic_on_oom=0\" >> \/etc\/sysctl.conf<\/strong><\/pre>\n<\/h4>\n
Cas d’un processus trait\u00e9 par “OOM-Killer”<\/h4>\n
\nUn matin, notre supervision nous a alert\u00e9 d’une indisponibilit\u00e9 de la base PostgreSQL survenue en pleine nuit chez notre client. Le message d’erreur \u00e9tait le suivant :<\/p>\n2020-12-24 03:08:32.650 UTC [20332] LOG: server process (PID 9725) was terminated by signal 9: Killed\r\n2020-12-24 03:08:32.650 UTC [20332] DETAIL: Failed process was running: select result.fn_agreg_rumresultdaily();\r\n2020-12-24 03:08:32.650 UTC [20332] LOG: terminating any other active server processes\r\n2020-12-24 03:08:32.650 UTC [12164] WARNING: terminating connection because of crash of another server process\r\n2020-12-24 03:08:32.650 UTC [12164] DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.\r\n2020-12-24 03:08:32.650 UTC [12164] HINT: In a moment you should be able to reconnect to the database and repeat your command.\r\n2020-12-24 03:08:32.651 UTC [12288] WARNING: terminating connection because of crash of another server process\r\n2020-12-24 03:08:32.651 UTC [12288] DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.\r\n2020-12-24 03:08:32.651 UTC [12288] HINT: In a moment you should be able to reconnect to the database and repeat your command.\r\n2020-12-24 03:08:32.655 UTC [12287] WARNING: terminating connection because of crash of another server process\r\n2020-12-24 03:08:32.655 UTC [12287] DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.\r\n2020-12-24 03:08:32.655 UTC [12287] HINT: In a moment you should be able to reconnect to the database and repeat your command.\r\n2020-12-24 03:08:32.657 UTC [12286] WARNING: terminating connection because of crash of another server process\r\n2020-12-24 03:08:32.657 UTC [12286] DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.\r\n2020-12-24 03:08:32.657 UTC [12286] HINT: In a moment you should be able to reconnect to the database and repeat your command.\r\n2020-12-24 03:08:32.661 UTC [12291] WARNING: terminating connection because of crash of another server process\r\n2020-12-24 03:08:32.661 UTC [12291] DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.\r\n2020-12-24 03:08:32.661 UTC [12291] HINT: In a moment you should be able to reconnect to the database and repeat your command.\r\n2020-12-24 03:08:32.661 UTC [12162] WARNING: terminating connection because of crash of another server process\r\n2020-12-24 03:08:32.661 UTC [12162] DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.\r\n2020-12-24 03:08:32.661 UTC [12162] HINT: In a moment you should be able to reconnect to the database and repeat your command.\r\n2020-12-24 03:08:32.664 UTC [12285] WARNING: terminating connection because of crash of another server process\r\n.....<\/pre>\n
2020-12-24 03:08:32.752 UTC [10939] HINT: In a moment you should be able to reconnect to the database and repeat your command.\r\n2020-12-24 03:08:32.823 UTC [20332] LOG: all server processes terminated; reinitializing\r\n2020-12-24 03:08:33.161 UTC [12295] LOG: database system was interrupted; last known up at 2020-12-24 03:05:33 UTC\r\n2020-12-24 03:08:33.162 UTC [12297] FATAL: the database system is in recovery mode\r\n2020-12-24 03:08:33.162 UTC [12296] FATAL: the database system is in recovery mode\r\n2020-12-24 03:08:33.164 UTC [12298] FATAL: the database system is in recovery mode\r\n2020-12-24 03:08:33.245 UTC [12352] FATAL: the database system is in recovery mode\r\n2020-12-24 03:08:33.245 UTC [12350] FATAL: the database system is in recovery mode\r\n2020-12-24 03:08:33.246 UTC [12353] FATAL: the database system is in recovery mode\r\n2020-12-24 03:08:33.246 UTC [12354] FATAL: the database system is in recovery mode\r\n2020-12-24 03:08:33.249 UTC [12355] FATAL: the database system is in recovery mode\r\n2020-12-24 03:08:33.250 UTC [12356] FATAL: the database system is in recovery mode\r\n2020-12-24 03:08:33.877 UTC [12295] LOG: database system was not properly shut down; automatic recovery in progress\r\n2020-12-24 03:08:33.883 UTC [12295] LOG: redo starts at 219E\/595E1A0\r\n2020-12-24 03:08:36.936 UTC [12360] FATAL: the database system is in recovery mode\r\n2020-12-24 03:08:37.355 UTC [12361] FATAL: the database system is in recovery mode\r\n2020-12-24 03:08:38.184 UTC [12363] FATAL: the database system is in recovery mode\r\n2020-12-24 03:08:41.792 UTC [12366] FATAL: the database system is in recovery mode\r\n2020-12-24 03:08:44.189 UTC [12369] FATAL: the database system is in recovery mode\r\n2020-12-24 03:08:44.191 UTC [12370] FATAL: the database system is in recovery mode\r\n2020-12-24 03:08:46.792 UTC [12373] FATAL: the database system is in recovery mode\r\n2020-12-24 03:08:51.751 UTC [12295] LOG: invalid record length at 219E\/6D68EE68: wanted 24, got 0\r\n2020-12-24 03:08:51.751 UTC [12295] LOG: redo done at 219E\/6D68EE40\r\n2020-12-24 03:08:51.751 UTC [12295] LOG: last completed transaction was at log time 2020-12-24 03:08:32.212985+00\r\n2020-12-24 03:08:51.757 UTC [12295] LOG: checkpoint starting: end-of-recovery immediate\r\n2020-12-24 03:08:51.795 UTC [12378] FATAL: the database system is in recovery mode\r\n2020-12-24 03:08:56.195 UTC [12383] FATAL: the database system is in recovery mode\r\n2020-12-24 03:08:56.196 UTC [12384] FATAL: the database system is in recovery mode\r\n2020-12-24 03:08:56.796 UTC [12385] FATAL: the database system is in recovery mode\r\n2020-12-24 03:08:58.621 UTC [12295] LOG: checkpoint complete: wrote 120927 buffers (46.1%); 0 WAL file(s) added, 0 removed, 104 recycled; write=6.753 s, sync=0.022 s, total=6.865 s; sync files=62, longest=0.022 s, average=0.000 s; distance=1701059 kB, estimate=1701059 kB\r\n2020-12-24 03:08:58.675 UTC [20332] LOG: database system is ready to accept connections\r\n\r\n\r\n<\/pre>\n
Dec 24 03:08:31 VM-client kernel: [ pid ] uid tgid total_vm rss nr_ptes swapents oom_score_adj name\r\nDec 24 03:08:31 VM-client kernel: [ 7801] 26 7801 609660 5736 134 0 0 postmaster\r\nDec 24 03:08:31 VM-client kernel: [ 9725] 26 9725 1692322 1571644 3200 0 0 postmaster<\/span><\/strong>\r\nDec 24 03:08:31 VM-client kernel: [11225] 26 11225 612080 19332 341 0 0 postmaster\r\nDec 24 03:08:31 VM-client kernel: [11261] 0 11261 30815 58 17 0 0 anacron\r\nDec 24 03:08:31 VM-client kernel: [11447] 26 11447 611520 18491 325 0 0 postmaster\r\n...\r\nDec 24 03:08:31 VM-client kernel: Out of memory: Kill process 9725 (postmaster) score 786 or sacrifice child\r\nDec 24 03:08:31 VM-client kernel: Killed process 9725 (postmaster) total-vm:6769288kB, anon-rss:4323864kB, file-rss:0kB, shmem-rss:1962700kB\r\nDec 24 03:10:02 VM-client systemd: Created slice User Slice of postgres.<\/pre>\n
\nLe serveur de notre client ne disposant que de 8Go de RAM, et surtout , pas de swap affect\u00e9 au syst\u00e8me.<\/p>\nLes bonnes pratiques avec PostgreSQL<\/h4>\n
\nNous avons donc demand\u00e9 \u00e0 notre client de cr\u00e9er cet espace SWAP sur le syst\u00e8me, 4 Go pour le moment seront affect\u00e9s.<\/p>\n
\nPar d\u00e9faut, ce seront des pages de 2Mo que l’on pourra allouer.<\/p>\nsysctl -w vm.nr_hugepages=1024\r\n<\/span><\/strong>ou bien : echo \"vm.nr_hugepages=1024\" >> \/etc\/sysctl.conf<\/span><\/strong><\/pre>\nsysctl -w vm.overcommit_memory=2\r\n<\/span><\/strong>ou bien directement dans le fichier \/etc\/sysctl.conf : echo \"vm.overcommit_memory=2\" >> \/etc\/sysctl.conf<\/strong><\/pre>\nsysctl -w vm.overcommit_ratio=75\r\n<\/span><\/strong>ou bien directement dans le fichier \/etc\/sysctl.conf : echo \"vm.overcommit_ratio=75\" >> \/etc\/sysctl.conf<\/strong><\/pre>\n<\/a><\/a><\/a>","protected":false},"excerpt":{"rendered":"