Bonjour, à tous J’ai un souci que j’essaie de régler depuis plus d’un an sans succès. Je suis sous buster avec un Odroid N2 de 64 G et 4 M de mémoire eMMC et Jeedom 4.3.21 Mon problème est que jeedom se plante systématiquement tout les 25 jours environ. La mémoire vive baisse tous les jours jusque planté le systéme dés qu’elle passe sous les 20% de disponibilité. Je le détecte avec la surveillance par scenario en envoi de sms de l’état de la mémoire vive et de la charge systéme 1mn via le plugin monitoring. Pour palier a cela j’ai remonter progressivement le swapiness de 10% à 30% pensant que le swap allait reprendre la main. Mais cela n’a fonctionné que 10 jours. La mémoire vive dispo à fait le yoyo passant de 25% et remontant a 40% deux fois de suite. Je pensai alors avoir trouver la parade. Mais ce matin la console monitoring était encore HS. Tous les chiffres étaient vide. Il me faut donc impérativement redémarrer jeedom…Je cherche de l’aide car je suis arrivé au bout de mes actions et recherche sur le forum et sur le net. Je galère depuis plus d’un an à essayer de trouver une parade pour stabiliser jeedom mais la !! je ne vois plus. J’ai passé le plugin moniteur en mode debug espérant avoir plus d’info. Merci pour votre aide.
Salut,
Peux tu donner la liste des plugins utilisés ?
Une copie de la page santé ?
Tu dois avoir un plugin qui bouffe de la ram (memory leak)
Il faudrait désactiver un par un pour voir lequel sauf si un membre sait quel tel plugin a le souci.
La parmi les tiens je ne vois pas de plugin que je connais qui aurait le souci
comme tu peux le voir j’en ai déjà désactivé plusieurs, à tour de rôle et laissé déconnecté la plus grand nombre. j’ai optimiser l’archivage également. je suis comme toi je ne vois pas quelle plugin pourrait encore posé souci. Par contre ce que je comprends pas c’est que le swap devrait palier à cela non ? Que le swapiness soit a 10% ou 30% rien ne change. Plantage quand même
Buster en 64bits au lieu du 32bits ne peut-il pas être source de problèmes ?
Bonjour @lapaupiere
Je n’ai pas assez de connaissance pour cela. Je vais creuser de ce coté là aussi.
Merci
Si pi autre que 4 ou 5, oui.
Pour les odroid (smart?) Je ne sais pas si la version 64 impact jeedom.
Hello @Vandoule
J’ai souvenir de pas mal de sujets du style sur le plugin-wifilightv2, par ex :
Tu peux nous faire un top pour voir quels sont les process les plus gourmands ?
Bad
Sinon, c’est pas sympa d’avoir désactivé le plugin-jmqtt 
Merci à vous tous pour votre aide.
Désolé je sors du taf. pas pu vous répondre avant.
Concernant jmqtt et la autres déjà désactivé c’est justement pour trouver celui qui peut générer ce conflit.
je vais donc couper aussi le pluging wifilightV2 pour faire un test.
Faire un top c’est quoi ? une image du moteur de taches ou des logue en temps réel ?
Voila déjà une image du moteur de taches mais on est loin d’avoir tout d’affiché. dite moi si c’est cela que vous voulez ?
et aussi une image des logues en temps réel pareil ets ce bien cela dont vous avez besoin ?
se connecter en ssh, via putty par exemple, se logguer et faire htop, commande linux
Normalement, le plugin wifilightV2 surveille le memory leak et redémarre les demon (entre 2h et 5h) si la mémoire utilisée augmente trop > 100000 ko. De plus, il affiche régulièrement la mémoire dans les logs _tuya et _dem.
Enfin, il y a un message qui s’affiche :
Restart Deamon memory: xxxx ko
Donc si c’est lui, il y a des traces un peu partout.
J’ai déjà signalé cela avec la fonction :
socket_read
J’ai modifié la lib mdns
le seul endroit où cela reste c’est avec le type Yeelight V1
qui normalement ne devrait pas être utilisé.
voila déjà le htop @anon53349806
pour @bernardfr.caron tu me parle un peu en chinois. 
comme je l’ai desactivé je devrais deja voir si ma mémoire chute encore de la même manière. je vais aussi regarder en paralle avec les elements que tu viens de me donner. Enfin je vais essayer.
ben non, j’ai écrit que les logs _cmd et _tuya contiennent la mémoire occupée par le plugin et que le centre des messages contient un message si le plugin a vu un souci.
Enfin, j’ai écrit quel type de périphérique pourrait encore provoquer le souci.
Désolé après relecture un peu plus compréhensif
le plugin wifilightV2 n’est pas très utilisé. dans ses log RAS avec ce que tu me donne comme info. les voila ci dessous.
merci a toi
ce n’est ni le log _dem ni le log _Tuya
Mais ça ne me sert à rien, c’est à toi de voir si la mémoire utilisée augmente et si oui de me l’indiquer.
Sans parler du message.
désolé
dans mes logs tuya, cmd et dem, je n’ai rien de particulier.
pour la conso mémoire je suis au alentour de 3500ko
pas de restart demon non plus
suis passé en debug aussi pour un meilleurs suivi
Hello @Vandoule ,
Oui, ma demande n’est effectivement pas claire, utilise la commande sudo top -b -n1 -o'%MEM' et post le résultat ici en texte préformaté (bouton </>) stp
Cette commande affiche entant que root tous les processus, classé par conso mémoire (1x).
Bad
Mon commentaire caché était évidement humoristique,
aucunement besoin de te justifier d’utiliser/activer un/mon plugin ou non 