Typo + exo not in submissions

This commit is contained in:
nemunaire 2016-10-06 03:58:52 +02:00 committed by Pierre-Olivier Mercier
commit 6fd83df1fd
6 changed files with 93 additions and 73 deletions

View file

@ -28,11 +28,11 @@ programme d'initialisation en utilisant des systèmes de fichiers virtuels, mis
à disposition par le noyau.
Ces systèmes sont virtuels, car ils ne correspondent à aucune partition d'aucun
disque : l'arborescence est créé de toute pièce par le noyau pour trier les
disque : l'arborescence est créée de toute pièce par le noyau pour trier les
informations mises à disposition, mais il n'est pas toujours possible d'y
apporter des modifications.
Linux emploi de nombreux systèmes de fichiers virtuels :
Linux emploie de nombreux systèmes de fichiers virtuels :
- `/proc` : contient, principalement, la liste des processus (`top` et ses
dérivés se contentent de lire les fichiers de ce point de montage) ;
@ -44,14 +44,14 @@ Linux emploi de nombreux systèmes de fichiers virtuels :
l'UEFI ;
- ...
Tous ces systèmes de fichiers sont généralement exclusivement stocké en
Tous ces systèmes de fichiers sont généralement exclusivement stockés en
RAM. Pour rendre une modification persistante, il est nécessaire de modifier un
fichier de configuration qui sera chargé par le programme d'initialisation. Par
exemple, pour modifier les paramètres du noyau, on passe par le fichier
`/etc/sysctl.conf` et du programme `sysctl`.
## Exercice
## Exercices
### `rev_kdb_leds.sh`
@ -118,9 +118,22 @@ user:[4026531837]
uts:[4026531838]
```
## Rendu
### Fichiers
### Questions
Rendez vos scripts `rev_kdb_leds.sh` et `procinfo`.
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
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é par le système de paquets de la distribution.
Il arrive quelque fois que le serveur de base de données soit tué par
l'OOM-killer alors que le serveur applicatif
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 ?