2017-10-22 20:40:47 +00:00
|
|
|
\newpage
|
|
|
|
|
|
|
|
Gestion de la mémoire
|
|
|
|
=====================
|
|
|
|
|
|
|
|
## OOM killer
|
|
|
|
|
|
|
|
<!-- https://lwn.net/Articles/590960/ -->
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Rendu
|
|
|
|
|
|
|
|
### Questions
|
|
|
|
|
|
|
|
Sur le serveur `antares`, un serveur applicatif critique tourne aux côtés de sa
|
|
|
|
base de données PostgreSQL. Le serveur applicatif étant connu pour produire un
|
2017-10-23 20:25:51 +00:00
|
|
|
grand nombre de *leak*, il est relancé chaque nuit. Le serveur applicatif tourne
|
|
|
|
en *root* car plus personne ne sait le paramétrer ; la base de données a été
|
|
|
|
installée par le système de paquets de la distribution.
|
2017-10-22 20:40:47 +00:00
|
|
|
|
|
|
|
Il arrive quelque fois que le serveur de base de données soit tué par
|
|
|
|
l'OOM-killer alors que le serveur applicatif utilise largement plus de mémoire
|
|
|
|
à la fin de la journée.
|
|
|
|
|
|
|
|
1. Quel paramètre du processus pourrait-on modifier pour que ce soit le serveur
|
|
|
|
applicatif qui aie plus de chance de se faire tuer par l'OOM-killer ?
|
|
|
|
|
|
|
|
2. Pourquoi est-ce le serveur de base de données qui est principalement tiré au
|
|
|
|
sort pour être tué en cas de manque de mémoire plutôt que le serveur
|
|
|
|
applicatif qui occupe pourtant bien plus de mémoire ?
|