Comme vous pouvez le voir sur cette capture, la charge du serveur à dépasser
les 140. Sur un autre graphique le nombre de processus est passée d'une
centaine à plus de 300.

La raison est simple, un répertoire NFS monté le 4 dans la journée, puis le
serveur qui partage est éteint dans la soirée (enfin le 5 au matin, vers 1
heure 30).
Résultat le client NFS attend pour une durée infinie que le serveur NFS
reviennent, bloquant ainsi une partie du serveur: chaque demande d'accès à un
fichier du réseau est mis en attente.
La solution est pourtant simple, il suffit de monter le répertoire NFS avec
l'option soft, ce qui évite ce genre de comportement: lors d'une
demande, le client NFS essaye de se connecter au serveur, si le serveur ne
répond pas une erreur d'E/S est générée.
Malgré cette charge monstrueuse, le serveur (pas le serveur NFS) n'a pas eu
le moindre problème pour compiler Wine pour le projet PlayOnLinux, même si la
compilation fut plus longue que d'habitude.
NB: Pour ceux qui ne savent pas ce que signifie le load average : http://fr.wikipedia.org/wiki/Load_average
RMQ: Vous pouvez remarquer qu'il n'y a plus d'information à un certain moment,
c'est simplement la base de donnée qui n'était plus en état de supporter de
nouvelle connexion pour que les outils de surveillance fonctionne, le service
affecté par le partage NFS utilise la BDD, au bout d'un moment ça finit par
coincer.