Tout dépend de ta politique :

soit laisser durer l'uptime jusqu'au plantage
soit rebooter régulièrement pour mettre à jour le kernel et les libs,
comme dit le collègue, une à deux fois par an, en fonction des alertes
aussi (voir les ML Debian dans mon cas)

un autre paramètre est... les caractéristiques du penguin vs ce qu'il
fait tourner et l'enjeu de sécurité. La fragmentation de la ram dispo,
les fuites de ram des applics, etc... en fonction des applics... et une
station sera toujours moins fiable qu'un serveur dépouillé du superflu.

Mon premier serv chez OVH, ks25865, a été rendu avec 1656 de jours
d'uptime (une lenny sur un pentium IV)... Now, la machine la plus
vieille du parc est un 4c/8t Xeon  64Go ram faisant tourner une
vingtaine d'instances, le pire que j'ai du faire est 700 jours (et je ne
m'en vante pas). Sur cette même machine, j'ai eu un début de vrille
dernièrement, elle n'avait pas 300 jours d'uptime. Un neutrino passé à
travers l'ECC de la ram ? ;) On doit la rendre en fin d'année après 5
années et c'était déjà à l'époque pas du neuf... mais bon, les bécanes
OVH, séducosto.

J'ai jamais réussi à corréler quoi que ce soit... Sur un serveur tout du
moins. En environnement GNU/Linux Debian Xen, que du compilé, standard
et pas de java, ça semble pas "s'user"...


Sur une station, c'est beaucoup plus clair.

Si c'est une Debian pure, montée à la mano, avec un window manager
frugal (OpenBox ou WindowMaker), en 365/24, la bête - même surmenée - va
avoir un uptime de plus de 200-300j facile.

Avec une Ubuntu 18.04 LTS et Gnome 3 dessus, atteindre 120j est un
exploit, mais bon, c'est Gnome 3 : super beau, pas super fiable :)
Accessoirement, les fuites mémoire sont légion et ça fini par remonter
le "plancher" de la RAM :)

Toutefois, pour plein de raisons, Ubuntu en station, c'est quand même
bien plus pratique (et Gnome 3 bien tuné, c'est quand même très beau)...

-- 
Stéphane Rivière
Ile d'Oléron - France

_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/

Répondre à