Re: Partitionnement d'un serveur web
Bonsoir,
Pascal Hambourg, au 2019-01-18 :
> Le 17/01/2019 à 11:00, Daniel Caillibaud a écrit :
> > C'est d'ailleurs un argument pour ne pas mettre de swap du tout, pour que
> > les oomkill arrivent dès que ça sature sans attendre l'agonie du système
> > (même si ça devrait jamais arriver, avec un dimensionnement correct en
> > amont).
>
> Avec deux inconvénients non négligeables : le système ne
> tolère pas les surcharges passagères, et on ne choisit pas les
> processus à tuer, on doit faire confiance à l'OOM killer.
Au risque de paraître insensé, quitte à compter sur l'OOM killer
pour faire le ménage de manière efficace, autant configurer le
noyau pour déclencher un panic_on_oom, tout en redémarrant
immédiatement en cas de panic (option panic=-1 au boot, de
mémoire). D'expérience, les tentatives de remises sur les rails
de machines ayant subit un OOM se sont souvent soldées par des
redémarrages au bout d'un temps déraisonnable, passé à se
gratter la tête essentiellement...
Certains systèmes peuvent être configurés pour ne pas autoriser
la sur-allocation de mémoire ; c'est la configuration par défaut
de l'OS au borsalino il me semble. Dans ce cas, l'OOM killer
n'est jamais appelé car toute tentative de malloc au delà des
limites se solde par un pointeur nul et un errno réglé à ENOMEM,
voir malloc(3). Si le service à assurer gère correctement cette
erreur lors de sa tentative d'allocation de mémoire, alors il
devient possible de remonter un message comme quoi la machine
est saturée, au lieu de commencer un nouveau traitement qui
aggraverait la situation.
Par défaut, Debian GNU/Linux est configuré pour faire de la
sur-allocation heuristique, d'où les appels à l'OOM killer en
cas de saturation de mémoire. La documentation du noyau donne
un peu plus de détails à ce sujet :
https://www.kernel.org/doc/html/v4.19/vm/overcommit-accounting.html
Bien à vous,
--
Étienne Mollier <etienne.mollier@mailoo.org>
Reply to: