Comme me la conseillé @Fabrice j’ai réglé la swapiness à 60% il y 10 jours pour faire des tests et j n’ai pas enclenché le reboot du Démon ZwaveJs par scénario hebdomadaire
Voici le retour 10 jours plus tard:
Il y a 9 jours sans aucune raison Jeedom a redémaré tout seul sans aucune raison connue !! Sa mémoire était à plus de 40% à ce moment là !! Pourquoi a t’il redémaré tout seul et comment est ce possible ??
Après le redémarrage, la mémoire est remontée à 60% mais chute inlassablement depuis 8 jours Image ci dessous.
Ce matin la mémoire après 10 jours de fonctionnement la mémoire n’est que de 32%. Je ne devrais donc pas tarder à planter Jeedom si je ne fais rien !!
Comme on peut le voir très peu de swap utilisé et de plus déclenché très tardivement. Le déclenchement du swap à eu lieu à 35% de mémoire vive alors que le swapiness est réglé a 60%… Je ne comprends donc pas non plus ce fonctionnement !!
J’ai donc tenté un redémarage du démon ZwaveJs comme le fait @FIESTA pour Xiaomi mais malheureusement cela ne change rien sur ce plugin. Dommage…aucun impact sur ls mémoire qui ne remonte pas.
Je n’ai d’autre choix que de rebooter jeedom pour récupérer de la mémoire avant le plantage car sinon ca me fait du dégât dans les scénarios et les plugins.
Apres reboot de Jeedom ce matin, remonté immédiate de la mémoire à 65%
J’avoue ne plus savoir comment gérer et stabilisé Jeedom avec ce plugin ZwaveJs qui me pollue la vie
J’ai même le sentiment que ca s’aggrave de mois en mois avec des redémarrages obligatoires tous les 10 jours !!
Je viens de désactiver mes 4 compteurs d’énergie sous zwave afin de voir si ce n’est pas une piste de pollution.
Donc à suivre; Si vous avez d’autres idées, Messieurs je suis preneur.
Bon c’est pas vraiment une solution mais j’en parle quand même parce que si tu es sûr que c’est un soucis avec ZwaveJS et que tu as un autre matériel tu peux aussi penser à monter zwavejs et mosquitto sur une autre machine (via snap ou docker) et utiliser jMQTT pour récupérer les infos sur Jeedom.
Tu n’auras pas tout sur la même machine mais c’est aussi une force et au moins ça déchargera ta machine Jeedom qui n’a pas l’air de gérer comme il faut.
Bonjours Messieurs et merci pour avoir pris le temps de me répondre
je vais regarder si mes soucis de fuite mémoire ne sont pas du à mes compteurs d’Energie qui sont a mon avis les plus chronophage sur ce plugin zwavejs.
En fonction de l’analyse j’étudierai votre proposition de secours.
Par contre je ne suis pas certain de tout décrypter du premier coup de ce que dit @Bison avec(docker, snap).
J’ai un vieux raspbery 3 qui traine que je peux donc utiliser pour zwavejs. Mais pour quelle raison mon souci du odroid ne serait pas le même sur mon Raspy ?
Disons que comme le principe n’est pas de remonter un Jeedom et d’y installer le plugin Zwave-JS mais plutôt directement l’application originale (zwave-js-ui), il est possible que ce problème ne se produise pas. Disons que c’est à tenter si tu ne trouves pas d’autres pistes pour régler ton soucis qui doit être bien prise de tête.
Bonjour
je suis depuis un moment ce post…
J’ai plusieurs Odroid N2 sous Jeedom et je n’ai vraiment aucun soucis …
et je n’ai jamais eu de problème de swap!
Je viens de tous les passer sous Debian 11 et ça marche aussi bien !
Donc,
Est ce que la version de Buster est une version pour Odroid-N2 (Odroid N2 / N2+ – Armbian) ?
Que donnent les commandes suivantes:
sudo uname -a
sudo swapon --show
sudo cat /proc/sys/vm/vfs_cache_pressure
Nous avons déjà eu des échange en MP. Tu avais pris la main à distance sur mon installation et avais gentiment créer à l’époque mon swap qui n’existait pas.
Je pensais que la création du swap allait résoudre mon problème de fuite mémoire de zwavejs mais comme tu peux le voir je suis toujours dans la galère.
Re-Bonjour
D’ou sort cette version de Buster?
je viens de vérifier sur un de mes N2 de test en Debian 10 et j’ai :
6.0.13-meson64 #22.11.2 SMP PREEMPT Sun Dec 18 16:52:19 CET 2022 aarch64 GNU/Linux
Ta version: Linux odroid-buster64 4.9.312-arm64
C’est une version plutôt ancienne car en 2022 on était déjà en Buster 5.10.12
Le kernel 4.9.12 est passé en EOL (end of Life) il y a plus d’un an!
ensuite install Jeedom avec la commande en ligne en ssh. Et une fois jeedom vierge démarré et connecté au market tu remets ton backup externalisé. Mais bon tu dois connaitre ça
Perso je préfère toujours refaire de zéro l’install sur un nouveau support que l’upgrade pour un changement d’Os. En cas de pb, il me reste le support initial avec mon jeedom qui tournait.
@Bison, @rennais35000, @cybertech et @Mips merci à vous. Je vais regarder tout cela de près et je reviendrais vous donner des news de cette maudite mémoire
Comme je m’y étais engagé voici un p’tit retour de ma dernier action à savoir déconnecter mes compteurs d’énergie Zvave afin de voir si cela peut alléger la charge et ainsi éviter cette chute de mémoire vive.
Et bien NON. Rien ne change. La mémoire chute aussi vite. Ce n’est donc pas une bonne piste. Ca à le mérite de le démontrer.
Bref, en voila la preuve dans le graphe ci dessous
Il ne me reste plus qu’a passer en debian 11 dés que je peux. (pas beaucoup de temps en ce moment)
Je reviendrai vers vous avec les tests mémoire pour ZwaveJs, en espérant que cette maudite mémoire fonctionne enfin correctement
Merci à tous et à bientôt pour de nouvelle aventure
J’ai déjà planté le système plusieurs fois avant de faire ce constat et ce post. D’où le titre de ce post !!! Et à chaque fois des dégâts si je ne le reboot pas moi même sous la barre de 28% de mémoire.
Ce matin je suis à 29% et comme tu peux le voir très peu de swap utilisé pourtant avec un swapines réglé 60% pour ces tests !!
J’ai fait mainte tests ou je pensais qu’a un moment il allait gérer via le swap et remonter sa mémoire mais il n’en est rien. A chaque fois il déclenche un peu plus de swap mais la mémoire continue de descendre grignoté par cette fuite mémoire du plugin zwaveJs.
Je peux même te donner les prochaines étapes
Le plugin monitor n’aura plus aucune valeur d’ici peu. Tous ses champs seront vide !
Si je relance le plugin Moniteur il va repartir quelques minutes réaffichant ses valeurs
Puis de nouveau vider ses champs quelques minutes plus tard L’étape d’après !! Jeedom se crache.
J’ai un scenario qui m’envoie une alerte SMS dés que le plungin Monitor est en déroute. Et c’est chaque semaine le même cinéma.
Alors je peux affirmer qu’il va se planter. Crois moi !!
Alors excuses moi mais je n’irai pas jusque là une nouvelle fois pour le redémontrer. Je vais donc le rebooter maintenant
N’oublions pas qu’initialement cette galère vient d’une fuite mémoire du plugin zwaveJs, comme démontré plus haut dans ce post avec l’aide de connaisseurs et peu être de ma version linux. (Encore merci a eux)
Il ne me reste donc plus comme solution qu’a passer en debian 11 rapidement en espérant que ce souci sera géré.
Bonjour,
Lorsque j’avais la Smart qui une carte Odroid C2 il me semble j’avais exactement le meme problème de Swap et de plantage tous les 15 jours. J’ai configuré plusieurs smart et ca tourne bien lorsqu’elle n’est pas trop chargée. Je n’ai jamais reussi a regler le problème. J’ai désactivé des plug in, modifié le swapiness etc… Je ne connais pas les différence entree la N2 et la C2 mais au final sur ma C2 je pense que c’est trop de plug in le problème.
Sur le forum il y a eu pas mal de sujet sur ce problème, ma solution a été de passer sur l’Atlas… https://community.jeedom.com/search?q=swap%20%23materiel-jeedom-hardware%3Ala-box-jeedom-smart
Le plugin qui me fait chuter la mémoire est zwaveJs
Des que je désactive je n’ai plus de souci.
Je n’ai plus d’autre choix, dés que j’ai un peu de temps que de passer sous debian 11. Si il ne gère pas correctement non plus je désinstalle ZwaveJs et bascule sous mon réseau zigbee
Mais là faut faire quelque chose car ca devient vraiment lourding.
