Plantage cyclique de Jeedom

Ok @Fabrice

Donc, pour être certain de bien comprendre
Je passe le swapiness à 60%.
Il se déclenchera donc plus tôt.
Je surveille le swap et je déclenche le code à 10% d’utilisation du swap.

C’est bien cela ?

Il faut passer le swapiness à 60 au lieu de 10.

Pour le moment, comme cela ne semble pas être la source de votre problème, je faites rien pour le reset du swap.

OK @Fabrice

Je fais cela de suite et vous tiendrai informé

Merci

De mon côté c est le plugin xiaomi qui a une fuite memoire donc au bout d un moment plus de memoire donc il declanche le swap mais vu que cela ne s arrête jamais sa fini par planter
Donc reboot du demon une fois par semaine et tout redevient normal
C est dégueulasse mais pas tros le choix pour le moment

Je vais tester vos solutions voire les mixer afin d’arriver au meilleurs résultat

Je vous tiendrai au courant

Merci à tous

Bonjour @Fabrice

Pour info
Swapiness réglé a 60% hier comme échangé. Ce matin, étonnamment avec 45% de méoire dispo à 7h00 et a l’instant 10h00 une mémoire á 42% de mémoire dispo je n’ai pas de déclenchement du swap. 100% de dispo swap dispo sur 1G.

Je me demande si en plus de cette fuite mémoire ZaveJS qui me bouffe ma mémoire tout les jours je n’ai pas un vrai souci de gestion de déclenchement de mon swap qui aggrave ce cas.

image

Bonjour Messieurs

Petit retour d’info de nos tests

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 !!

image

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%

image

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.

Merci pour votre aide

JM

Hello,

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.

ou mqtt discovery :stuck_out_tongue:

Ah oui j’ai pas le réflex désolé :laughing:

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.

Un peu de lecture : [Tuto] jMQTT + Mosquitto + ZWave-JS-UI (anciennement ZWaveJS2MQTT)

Le tuto a été fait avec une VM mais c’est à adapter si ça tourner directement sur un Rpi3.

Alors là !!! Bravo pour ton tuto @Bison
Chapeau !!

Je vais regarder cela de prêt. Je me permettrai de revenir vers toi si je m’y aventure car à premier vu niveau un peu haut pour moi.

Merci beaucoup pour ton aide

A suivre

JM

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

Bonjour @cybertech

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.

Merci pour ton aide

Voici la réponse à tes questions

image

root@odroid-buster64:~# sudo uname -a
Linux odroid-buster64 4.9.312-arm64 #1 SMP PREEMPT Wed Nov 23 00:32:45 CET 2022 aarch64 GNU/Linux

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!

Re-moi

Je ne me rappelle plus ou j’ai téléchargé cette version. Surement sur le site odroid ou linux. Mais oui ca fait un moment déjà.

Si ce n’est pas une bonne version alors il vaut peut être mieux que je passe directement en debian 11
non ?

Tes tests étant positifs, peux tu me donner un lien pour charger debian 11 pour odroid ?

Merci à toi

j’ai juste fait un upgrade classique…
apt update
apt upgrade
apt full-upgrade
apt autoremove --purge

Attention c’est très très très long!!

mais avant tout ça j’ai fait un clone sur mon PC de ma EMMC avec image USB (Tools for OSForensics - ImageUSB - Write an image to multiple USB Flash Drives)
Car jamais d’upgrade sans un backup / clone complet… c’est la base!!

tu peux aussi jeter un coup d’œil ici : Mettre à jour Debian 10 vers Debian 11 (Bullseye) – Le Crabe Info

Bonsoir,
J’ai mis celui-là qui tourne très bien.
https://xogium.performanceservers.nl/archive/odroidn2/archive/Armbian_23.02.2_Odroidn2_bullseye_current_6.1.11.img.xz

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 :slight_smile:

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.