tu peux nous donner plus d’explication ?
Vraisemblablement, il s’agit du daemon du plugin zwavejs qui prend 4.6% de ta RAM.
Il « semblerait » donc que ce plugin ait une fuite mémoire, si c’est celui qui te consomme toute ta RAM jusqu’au plantage.
Sinon, la méthode est la même pour identifier le plugin en cause (regarder que process prend toute la mémoire, savoir à quel plugin il appartient, décider s’il faut le tuer ou non).
Perso, j’ai défini des seuils de conso mémoire assez larges dans le plugin Monitoring, avec des alertes mail. Je regarde les process en faute à ce moment-là, je prends des logs et j’arbitre la tuerie.
merci @bad
j’ai pas ma de materiel zwave que je ne peux pas me passer. du coup je ne peux pas le couper pour tester.
j’ai plusieurs questions. qui peuvent également intéresser nos collègues du forum sur ton analyse très pertinente. désolé d’abuser 
1- peux tu me dire dans le dernier fichier que je t’ai envoyé comment tu as détecté que c’etait le plugin en lien avec les 4,6% du fichier précèdent !
2 - si ce plugin a une fuite mémoire je ne dois pas être le seul a avoir ce problème. et dans ce cas fut il remonter l’info au team ?
3- je me suis aussi fait des alertes sur monitoring afin d’essayé au mieux d’éviter le plantage. mais ça n’a pas marché puisque c’est arrivé à 1h00 cette nuit et hier soir j’avais pourtant plus de 40% de mémoire vive dispo. Donc vu que ce matin le plantage !! Monitoring complètement vide d’information
Pour l’automatiser un secours avant que ce plugin soit un jour corrigé as tu ou as tu connaissance d’un script qui pourrait automatiser le démarrage du plugin en défaut au travers de l 'analyse permanente des logs ?
C’est abusé, c’est toi qui abuses de penser que tu abuses ! 
Oui :
Le programme top donne les conso CPU, mémoire, ou autre, du plus petit au plus grand :
- 15 plus gros consommateurs de RAM →
top -b -c -n1 -o'%MEM' | head -n 22 - 15 plus gros consommateurs de CPU →
top -b -c -n1 -o'%CPU' | head -n 22
Une fois le PID (numéro du processus lancé) obtenu (première colonne de top), il s’agit de savoir qui est-ce, où est-il et qui l’a lancé pour savoir quoi faire : sudo ls -l /proc/5076/fd va fouiller dans les entrailles du processus avec le PID 5076, afin de savoir quels fichiers il a ouvert (/fd= file descriptor, donc les fichiers accédés) et eux peuvent donner un indice sur quel est le plugin.
Mais il y a pleins d’autres façon de retrouver qui-est-qui, par exemple le process php /var/www/html/core/class/../php/jeeCron.php cron_id=328 est le cron Jeedom numero 328, il suffit d’aller voir dans le moteur de tâches de Jeedom pour savoir, et le buter, ou pas.
Oui, pour ça tu peux ouvrir un ticket. Mais avant il faut t’assurer que c’est bien le plugin en cause.
Je n’ai pas mis en place ce genre d’automatise, mon Jeedom est très stable et n’a pas beaucoup de plugins (car presque tout est sur MQTT). Je préfère garder la main sur ce genre de diag.
Mais le process expliqué en (1) est globalement automatisable en script shell, il est possible de simplement écrire le résultat des top dans un log Jeedom (+ mail si besoin), ou d’aller plus loin en ajoutant en suit un kill du process le plus gourmand.
Le problème c’est que, autant les services du système linux sont fait pour mourir de façon inopinée et revenir à la vie tout seuls ensuite, autant les process ou les daemon Jeedom doivent souvent être gérés par Jeedom pour ne pas être en vrac ensuite.
Et là, après qu’un script ait (automatiquement) foutu la pagaille dans ton système, tu es obligé d’intervenir tout de suite, alors que si tu gardes la main, c’est selon tes envies/impératifs.
Bad
Merci beaucoup pour toutes ses explications @Bad
Je comprends mieux. Je vais me debrouiller pour pouvoir couper ce plugin quelques jours et voir ainsi si la memoire est plus stable. Si c’est confiirmé je ferais un tiicket
Je reviendrai vous donner de l’info. En tt cas merci beaucoup a vous tous pour votre aide.
1 « J'aime »
Il te demande le mot de passe de l’utilisateur root, qui n’est peut-être même pas défini (auquel cas, c’est très bien ainsi).
Je n’avais pas pensé au fait que de nos jours la quasi totalité des gens utilisent sudo et ne se loguent plus directement en root (c’est mieux, c’est moi qui ai de vieilles habitudes du temps d’avant sudo). J’ai modifié le script et la commande à utiliser pour pouvoir lancer le script via sudo et sauvegarder les données dans le répertoire racine de l’utilisateur.
La bonne pratique étant d’utiliser sudo, la commande à lancer est :
sudo bash monitor_swap.sh &
Le données seront sauvegardées dans le fichier utilisation_swap.txt situé dans le répertoire racine de l’utilisateur ($HOME ; généralement /home/nom_utilisateur)
Ok Merci @pommedapi
Je vais regarder ca demain.
Bonjour à tous
Comme convenu j’ai désactivé le plugin Z-wave JS ce matin afin de voir si c’est lui qui pollue de trop ma mémoire vive jusqu’au plantage de jeedom.
J’espère le voir rapidement. Normalement via l’historique sur le monitoring de la mémoire vive et du swap je devrait logiquement avoir un graph plus lisse.
Comme j’ai pas mal de matériel dessus dont l’alarme, l’eau chaude et une partie de mon chauffage, je ne pourrais pas le laissé arrêté plus de 3 jours. Après je le remets en service.
Pour @Bad voila les info via ssh après déconnexion du z-wave JS
mysql est à 7,5 % ce matin. Est ce toujours raisonnable hier il était a 4,2% . Mais visiblement il bosse en se moment puisque sa charge est a 122 ?
Bonjour @pommedapi bonjour à tous
Ca y est j’ai créé les 2 fichiers et lancé ton process du surveillance du swap. Voir image console ci dessous
Dans 24 h00 je vous ferais donc un retour sur le contenu du fichier
Comme il est lancé pour 24h00 je suppose que je devrait l’arrêté quand même vu le « & »
Quelles lignes de code stp pour revenir a l’état normal ?
Merci a toi
Image à 8h40
Bonjour,
Vous avez vu que la commande principale de votre shell script n’était pas installée ?
→ Pas de résultat.
Bonjour @jpty
non je n’ai pas vu. merci de l’info je suis novice sur ce type de code. j’y vais a taton
hier je me suis mis en root et ai entré le code suivant pour l’installation de smen.
apt-get update && apt-get upgrade && apt-get install smem. l’installation a eu lie. mais effectivement je ne sais pas si elle s’est bien passée
Quelle action dois je faire pour rectifier ?
Pour vérifier si smem est installé, il suffit de lancer la commande.
En ssh et en étant logué root, la commande d’installation est apt install smem
ou sudo apt install smem si pas en root
Il manque peut-être juste sudo dans le lancement de la commande dans le shell script.
voila le contrôle après vos ligne d’installation
Maintenant c’est bon. La commande smem est installée.
L’exécution du shell script devrait contenir un résultat.
Petit complément d’information @pommedapi
Pour info avec la commande « sudo bash monitor_swap.sh & » je n’arrive pas a enclencher la surveillance du swap pour 24 heures toutes les 10 minutes. Le systéme se bloque au bout d’une durée de 20 à 30 minutes.
Après recherche sur le net j’ai trouvé « sudo timeout 24h bash monitor_swap.sh & » qui me permet de lancer pour 24h
Pour ce faire il faut avant s’assurer que le timeout est bien installé
voici la ligne de commande a taper pour installer. « sudo apt-get install coreutils »
Il ne s’arrête plus au boit de 2 analyses mais il le respecte pas les 10 minutes entre chaque analyse. Parfois 5mn parfois 2 mn. Je n’ai pas réussi à faire mieux et je n’ai pas envi de mettre un « sleep 10 »
Donc pour 24 heure ça restera comme cela.
Voila à suivre
Je n’avais pas pensé au timeout de sudo 
Oui, effectivement, au bout d’un temps assez court, sudo coupe les droits root. Ça se configure, mais c’est une très mauvaise idée d’étendre ce timeout à 24h.
À noter que ça n’arrive pas quand on lance la commande directement en root.
Tu as trouvé une solution, c’est parfait 
Une alternative consisterait à utiliser screen ou tmux (ce qui est toujours un bon réflexe quand on administre une machine distante, mais on s’éloigne trop de Jeedom et on se rapproche trop de l’administration système en ligne de commande pour le coup).
Tu as raison mais ce n’est que 24hh00. Donc pas grave si c’est un peu bancale
On verra le resultat demain . Merci a toi pour ta reponse
JM
Bonjour Messieurs
Un peu d’info à mi parcours
A cette heure le plugin zwavejs est toujours déconnecté. je vais le laissé déconnecté encore 24h00 pour être certain, mais il faut reconnaitre qu’e nous sommes sur la bonne piste. @Bad Ton analyse était la bonne.
@pommedapi ton fichier de suivi est top
en regardant la dernière ligne nous restons dans les mêmes valeurs globale. depuis hier midi. je n’ai pas détecté de process gourmant en regardant dans le détail
Donc a suivre demain
