Le swap de 2Go ne bouge pas, il reste libre à 100%
Par contre la mémoire diminue de jour en jour.
Exemple ici, où il reste 802 Mo de libre alors que le RPI4 n’a plus été rebooté depuis 9 jours.
Je ne suis pas encore passé a Debian11 … seulement a Jeedom 4.4.6 sur Debian10. Et tout fonctionne bien.
Je vois des plugins comme JMQTT, Teleinfo ou encore worksLandroid qui utilisent Python3:
Je ne serais pas te répondre de manière juste. Je connais le problème pour le plugin RFXCOM et encore, c’est pondéré par rapport au nombre de périphériques RFXCOM que le plugin gère.
J’ai lu sur le plugin Xiaomi qu’il y avait le même problème.
Je pense attendre alors avant de migrer vers Debian11 …
J’ai eut tellement de soucis de ‹ fuite de mémoire › dans le passé (si on peut l’appeler comme ça) que je ne souhaite plus me frotter à ce type de problème aussi tôt.
Je ne suis pas sûr que ce soient les plugins qui soient en cause mais bien la version de Python 3
Il apparait clairement que la version 3.9.2 génère une fuite mémoire tandis que la 3.9.19 ne présente pas le souci.
Il y a donc une possibilité de repasser en version 3.9.19 afin de valider cette thèse et mettre hors de cause les plugins. Ce qui le cas échéant pourrait permettre à Jeedom et aux plugins de « bloquer la version »
Hum, effectivement la c’est un peu galère …
C’est a l’équipe Jeedom de trouver une solution pour forcer l’installation de Python 3.9.19 alors non?
Je vais bien sagement rester sur Debian10 pour le moment.
On a constate le même problème chez un ami qui est passe sur Debian11 et on a mis un scenario en place pour redémarrer les deamons des plugins en en question.
Non
Je n’ai pas encore détecté le moindre problème avec worxlandroid par exemple
Incorrecte également.
Tous les codes tournant sous 3.9.2 ne génère par forcément une fuite mémoire.
C’est plus complexe que cela, probablement certaines (versions de) libs en combinaison avec certaines versions de python
Il est même possible par exemple qu’une lib ai un problème dans sa version x, qui est la seule dispo pour 3.9.2 et que dans la version x+1 le problème ait été réglé mais mis à dispo que pour une version python > 3.9.2
Dans ce cas la version de python serait complètement hors cause.
Il y a beaucoup trop de raccourci fait autour de cette histoire
Ok super mais bon cela ne résout pas le schmilblick hein
Que faire en tant qu’utilisateurs de Jeedom?
On est d’accord qu’il y a des circonstances qui crées de l’instabilité en faisant les mises a jours, c’est alors aux développeurs des plugins d’en chercher les causes?
Pas simple cette histoire… je suis d’accord qu’il faut suivre l’évolution d’un système, rien que pour des questions de sécurité et de support mais migrer vers quelque chose qui peut causer des soucis a l’utilisateur n’est pas une bonne chose.
Ce que je vais faire c’est un backup de mon Jeedom et le migrer vers un Jeedom de test sous Debian 11 et tester le tout pendant un moment avant faire la mise a jour sur mon Jeedom de Prod… mais l’utilisateur lambda il fait quoi ?
Ton conseil @Mips serait de rester en Debian10 pour le moment? (je viens du monde MS Windows … mon expérience Linux est limite … )
J’ai fait un Top pour voir l’occupation mémoire
les plugins RFXCom, JMQTT n’apparaissent pas comme consommateurs de mémoires.
Python3 et le plugin deCONZ apparaissent continuellement.
deCONZ me semble normal car j’ai une douzaine de modules zigbee lié à la clef ConbeeII ça me semble donc logique qu’il utilise des ressources mémoire.