Tous,
Je me demandais s’il y avait des valeurs/metrics vicieux/obscurs auxquels il fallait prêter attention quand on tente de déterminer si un Linux a un uptime qui commence à être élevé (plusieurs années). Quand on a fait le tour des indicateurs standards, comment savoir si des problèmes qu’on a pourrait venir de là, et que donc un reboot serait utile (parce que n’étant pas de culture Windows, le ressort au reboot pour essayer au cas où de régler un problème, c’est pas mon délire).
Merci
On Wed, 3 Nov 2021 18:20:41 +0100 David Ponzone david.ponzone@gmail.com wrote:
Tous,
Je me demandais s’il y avait des valeurs/metrics vicieux/obscurs auxquels il fallait prêter attention quand on tente de déterminer si un Linux a un uptime qui commence à être élevé (plusieurs années). Quand on a fait le tour des indicateurs standards, comment savoir si des problèmes qu’on a pourrait venir de là, et que donc un reboot serait utile (parce que n’étant pas de culture Windows, le ressort au reboot pour essayer au cas où de régler un problème, c’est pas mon délire).
Bonjour,
vos infos étant vagues (quels problèmes ? De quels "indicateurs standard" avez-vous faire le tour ? Quelle distribution ?) je vous proposerai une idée vague.
"uname -a" ou "uname -r" : sur quel noyau tourne votre système ? Quel(s) noyau(x) sont présents sous /boot ?
À part cela je veux bien comprendre que vous ne souhaitez pas rebooter avec un bel uptime, mais si le problème XY venait d'un noyau pas à jour (peut-être installé mais non actif tant qu'il n'y a pas eu reboot) vous ne pourriez pas le faire prendre en compte (sauf acrobatie technique spéciale dont je n'ai pas le secret ni ne maîtrise : https://www.debian-fr.org/t/mise-a-jours-du-kernel-sans-reboot/34315/3).
Cordialement, Joyce MARKOLL
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)...
Je me demandais s’il y avait des valeurs/metrics vicieux/obscurs auxquels il fallait prêter attention quand on tente de déterminer si un Linux a un uptime qui commence à être élevé (plusieurs années). Quand on a fait le tour des indicateurs standards, comment savoir si des problèmes qu’on a pourrait venir de là, et que donc un reboot serait utile (parce que n’étant pas de culture Windows, le ressort au reboot pour essayer au cas où de régler un problème, c’est pas mon délire).
le reboot reste utile quand on maintient son serveur a jour, notamment pour avoir un kernel "up to date" ce qui evite de possibles problèmes de sécurité , et apporte des corrections de bugs. d une maniere générale un uptime superieur a un an est généralement dangereux car cela signifie que vous utilisez un kernel très probablement vulnérable. ici il ne s agit pas comme sous windows de "rebooter au cas ou ca reglerai un probleme, mais de rebooter apres de nomreuses mises a jour, pour être sur que toutes ces mises a jour sont bien actives.
Merci
Liste de diffusion du FRsAG http://www.frsag.org/
Le 2021-11-04 13:11, neo futur a écrit :
Je me demandais s’il y avait des valeurs/metrics vicieux/obscurs auxquels il fallait prêter attention quand on tente de déterminer si un Linux a un uptime qui commence à être élevé (plusieurs années). Quand on a fait le tour des indicateurs standards, comment savoir si des problèmes qu’on a pourrait venir de là, et que donc un reboot serait utile (parce que n’étant pas de culture Windows, le ressort au reboot pour essayer au cas où de régler un problème, c’est pas mon délire).
le reboot reste utile quand on maintient son serveur a jour, notamment pour avoir un kernel "up to date" ce qui evite de possibles problèmes de sécurité , et apporte des corrections de bugs. d une maniere générale un uptime superieur a un an est généralement dangereux car cela signifie que vous utilisez un kernel très probablement vulnérable. ici il ne s agit pas comme sous windows de "rebooter au cas ou ca reglerai un probleme, mais de rebooter apres de nomreuses mises a jour, pour être sur que toutes ces mises a jour sont bien actives.
Merci
Bon on s'éloigne de la discussion initiale... mais pour info, il y a la commande "checkrestart" (package debian-goodies) sous Debian pour savoir quels process/daemon redémarrer pour la prise en compte des nouvelles versions de lib/binaires.
Cordialement,
-- Jean-Yves LENHOF
Le Thursday 04 November 2021 13:20:52 Jean-Yves LENHOF via FRsAG a écrit :
Bon on s'éloigne de la discussion initiale... mais pour info, il y a la commande "checkrestart" (package debian-goodies) sous Debian pour savoir quels process/daemon redémarrer pour la prise en compte des nouvelles versions de lib/binaires.
needrestart est plus complet, et propose également de redémarrer les services (si en mode tty non scripté) avec un choix par défaut excluant ce qui pourrait poser problème.
Il prévient aussi quand il faut redémarrer la machine pour mettre a jour le noyau et/ou le microcode.
jeudi 4 novembre 2021, 13:30:17 CET Vincent Tondellier via FRsAG wrote:
needrestart est plus complet, et propose également de redémarrer les services (si en mode tty non scripté) avec un choix par défaut excluant ce qui pourrait poser problème.
Il prévient aussi quand il faut redémarrer la machine pour mettre a jour le noyau et/ou le microcode.
Je vais faire ma petite pub : j’ai fait un motd dynamique qui utilise needrestart ou checkrestart (selon ce qui est installé) pour prévenir s’il faut redémarrer des services ou s’il y a une mise à jour noyau en attente et donc qu’il faudrait redémarrer : https://framagit.org/luc/dynamic-motd
Ça affiche aussi d’autres infos (genre occupation disque, inode…).
Je trouve que c’est très pratique, ça fait des rappels dès qu’on se connecte en SSH.
Bonjour,
Personnellement, sous Debian, je reboot à chaque "révision" (10.4 -> 10.5, 11.0 -> 11.1, etc). Ca correspond la plupart du temps à une maj noyau et ça rythme pas mal les redémarrages, trouve-je.
Guy.
Le 08-11-2021 09:55, Luc Didry a écrit :
jeudi 4 novembre 2021, 13:30:17 CET Vincent Tondellier via FRsAG wrote:
needrestart est plus complet, et propose également de redémarrer les services (si en mode tty non scripté) avec un choix par défaut excluant ce qui pourrait poser problème.
Il prévient aussi quand il faut redémarrer la machine pour mettre a jour le noyau et/ou le microcode.
Je vais faire ma petite pub : j’ai fait un motd dynamique qui utilise needrestart ou checkrestart (selon ce qui est installé) pour prévenir s’il faut redémarrer des services ou s’il y a une mise à jour noyau en attente et donc qu’il faudrait redémarrer : https://framagit.org/luc/dynamic-motd
Ça affiche aussi d’autres infos (genre occupation disque, inode…).
Je trouve que c’est très pratique, ça fait des rappels dès qu’on se connecte en SSH.
La baisse de l'espace disque restant dans un système de fichier entraîne parfois des pertes de performances assez importantes.
En passant de 25% à 15% d'espace disque disponible par exemple, les performances sont parfois réduites de plus de 30%. Ça dépend évidemment du système du fichier et du type de charge sur la partition. C'est particulièrement visible sur ZFS par exemple.
Évidemment, redémarrer ne change rien. L'espace disque disponible et l'uptime sont parfois corrélés (à la durée de vie du service), donc c'est un indicateur à garder en tête quand "les performances se sont dégradées sans raison apparente".
Bon courage pour le diagnostic,
On Wed, Nov 3, 2021 at 9:22 PM David Ponzone david.ponzone@gmail.com wrote:
Tous,
Je me demandais s’il y avait des valeurs/metrics vicieux/obscurs auxquels il fallait prêter attention quand on tente de déterminer si un Linux a un uptime qui commence à être élevé (plusieurs années). Quand on a fait le tour des indicateurs standards, comment savoir si des problèmes qu’on a pourrait venir de là, et que donc un reboot serait utile (parce que n’étant pas de culture Windows, le ressort au reboot pour essayer au cas où de régler un problème, c’est pas mon délire).
Merci
Liste de diffusion du FRsAG http://www.frsag.org/
Hello,
En passant de 25% à 15% d'espace disque disponible par exemple, les performances sont parfois réduites de plus de 30%. Ça dépend évidemment du système du fichier et du type de charge sur la partition. C'est particulièrement visible sur ZFS par exemple.
+1. J’ai eu le problème récemment. Je me demandais pourquoi les perfs s’écroulaient, jusqu’à ce que je m’aperçoive qu’il ne restait que 50 Mo de libre sur le disque. Un zpool online -e a résolu le souci comme par magie.
Vincent
Hello,
pour ZFS, il est recommandé de ne pas dépasser les 80% de remplissage.
Cordialement, David
On Fri, 5 Nov 2021 08:04:13 +0100 Vincent Habchi vincent@geomag.fr wrote:
Hello,
En passant de 25% à 15% d'espace disque disponible par exemple, les performances sont parfois réduites de plus de 30%. Ça dépend évidemment du système du fichier et du type de charge sur la partition. C'est particulièrement visible sur ZFS par exemple.
+1. J’ai eu le problème récemment. Je me demandais pourquoi les perfs s’écroulaient, jusqu’à ce que je m’aperçoive qu’il ne restait que 50 Mo de libre sur le disque. Un zpool online -e a résolu le souci comme par magie.
Vincent
Liste de diffusion du FRsAG http://www.frsag.org/
Hello,
pour ZFS, il est recommandé de ne pas dépasser les 80% de remplissage.
+1
Je suis d’accord. C’est juste que j’avais mis en service un cache FastCGI, et je ne m’étais pas rendu compte à quel point il avait mangé du disque.
tmpreaper (sous linux) est pratique pour faire ce genre de ménage automatique.
Accessoirement le checksum=skein et atime=off, accélèrent de façon non négligeable ZFS...
La compression "basique" lz4 aide bcp aussi. Surtout quand on as des caches de données telles que du fastcgi avec plein de trucs redondant dedans... Le dedup est aussi a voir, mais il faut de la ram :)
/Xavier
Salut Xavier,
tmpreaper (sous linux) est pratique pour faire ce genre de ménage automatique.
Bah, maintenant j’ai de toute façon un cron qui efface le cache tous les soirs à minuit puis lance un spider (wget) pour le re-remplir.
Accessoirement le checksum=skein et atime=off, accélèrent de façon non négligeable ZFS...
Intéressant, il faut que je regarde. Je suis en LZ4, oui. Quant au DDUP, j’essaie de garder la RAM sous contrôle, parce que dans une VM, c’est ce qui coûte le plus…
Merci des tuyaux :)
Vincent
-
contact＠orditux.org -
David Durieux -
David Ponzone -
Guy Larrieu -
Jacques Lavignotte -
Jean-Yves LENHOF -
Luc Didry -
neo futur -
sr -
Théophile Helleboid -
Vincent Habchi -
Vincent Tondellier -
Xavier Beaudouin