Mémoire disponible qui diminue au fil des jours

bonjour à tous. Je viens de redémarrer mon Jeedom. Il affiche une mémoire disponible de 44%
Je sais que d’ici 1 mois environ , la mémoire disponible va tomber à environ 10% gelant l’ensemble du jeedom et m’obligeant à redémarrer.
Je souhaite surveiller cette mémoire afin de voir quel process/plugin utilise cette mémoire de façon anormale.
pouvez vous m’orienter afin d’effectuer cette surveillance ?

Merci beaucoup

Bonjour,

Il y a déjà beaucoup de posts posant cette question donnant des réponses variées qui

  • orientent vers certains plugins en particulier
  • donnent des commandes à exécuter (éventuellement dans une commande du plugin script) pour analyse

Avez-vous cherché ou on répète tout ici? :wink:

1 « J'aime »

Bonjour
Il y a aussi un post ou j’explique que ça peut être normal Linux ne libère la mémoire que si il en a besoin sinon il ne perd pas de temps à le faire. Donc un Linux tant machinalement a 100% de ram utilisée

Bonjour et merci beaucoup de vous occuper de mon cas. En effet, j’ai lu beaucoup de postes sur des fuites de mémoire. En ce qui me concerne je suis toujours sous debian 10 et je n’ai pas migré sur la dernière version du core jeedom. En effet, Linux gère sa mémoire tendant en effet à l’occupation totale de cette dernière mais ce qui est embêtant c’est que lorsque il reste 10 % de mémoire disponible, tout le système se fige les scénarios ne s’exécutent plus et le zwave ne réagit plus. J’ai tenté de redémarrer le démon de certains plugins pour voir si je récupère de la mémoire mais cela ne donne rien de particulier à part récupérer deux ou trois pour cent. C’est un phénomène chez moi qui est nouveau. Peut-être que le plugin conso ou le nouveau plugin z wave JS est très gourmand en mémoire…

Dun autre coté votre machine ne dispose pas de beaucoup de ram.

quelqu’un peut t il me dire à quoi correspond une connexion active ?

J’ai remarqué mais cela doit être normal que plus il y en a et moins il y a de mémoire disponible …

image

Comment diminuer le nombre de connexion active et comment savoir à quels plugins correspondent les connexions ?

Merci beaucoup

En effet, RPI3B… Peut être que je lui en demande un peu trop maintenant avec des plugin un peu trop gourmands en ressources : MQTT / Plugin Conso …

Chez moi le plugin xiaomi et reolink me font diminuer la memoir jusqu’au crash
J ai un scénario qui relance le demon de ces plugin tous les 3 jour
Et plus de crash
Un problème de version python si j ai bien compris

1 « J'aime »

Merci pour ta réponse. Je suis toujours en debian 10 et je n’ai pas mis à jour mon jeedom vers la dernière version du core, je ne suis pas concerné par ce problème récurrent à cause python… Dans ton cas, un simple redémarrage du plugin Xiaomi suffit pour récupérer de la mémoire?

Oui
Quand je redémarre les plugin incriminé je reviens immédiatement a 80% de mémoire libre

Pour information :
Le plugin wifilightV2 a 2 daemons. Jusque la 4.3 pas de souci de fuite mémoire. Depuis 4.4 et Debian 10 toujours il y a fuite mémoire et c’est suite à un appel au core.
En dehors d’un daemon ce n’est pas important mais dans un daemon ça l’est.
J’ai remis le contrôle de la mémoire utilisée et redémarrage des daemons.

Merci pour ta réponse, c’est très intéressant… Je comprends que WiFilight V2 pose problème de fuite de mémoire sous debian 10 et core jeedom 4.4 ? J’ai désactivé le plugin cet après-midi par le plus grand des hasards. Je vais voir dans les prochains jours si la mémoire disponible reste correct et stable. Je suis cependant toujours sur le core jeedom 4.3… du coup mon problème ne doit pas venir de ce plugin… Es tu le développeur de WiFi LiteV2 ?

oui.
A te lire rien à voir avec le plugin
et la dernière version contrôle cette fuite mémoire.

Merci pour ta réponse