Je partage ton avis. Même si j’ai pour le moment opté pour un redémarrage de certains deamons en dessous d’un certain seuil de RAM disponible, je trouve que c’est loin d’être top comme solution.
C’est bien pour cela que je me penche sur l’upgrade python.
Tu peux connaitre les plugins qui utilisent python3 en allant sur : Réglages → Système → Configuration → >_OS/DB → Vérification des packages système
Merci
Pouah ya du monde j’ai aussi, ça veut dire autant de restart de demon que ce que je vois comme plugin qui utilisent python3 ?
Il faut regarder ceux qui sont le + consommateurs, mais d’après mes constats XiaomiHome arrive en tête, ensuite RFXcom et Broadlink
Juste pour être sûre de pas comparer des carottes et des choux fleurs tu utilises quelles commandes ou manip ?
J’ai pas retrouvé dans la conversation.
Merci.
C’est dans : Réglages → Système → Configuration → >_OS/DB → >_Administration système → Puis tu sélectionnes Memory Usage dans la partie gauche
Pour donner une idée; j’ai enregistré l’état à 16h20
Et voici le même moins d’une heure après
En moins d’une heure, XiaomiHome a consommé 6Mo qu’il n’a pas résitués
Ah mince tu me fais découvrir tous ces menus ou c’est marqué 'touche pas trop a ça petit c**" lol
Je check de mon côté.
Merci.
Il faut juste toucher avec les yeux 
Sur une autre VM qui tourne en // j’ai upgradé Python3 (version en cours 3.9.19) et j’ai installé ces plugins consommateurs
A 16h20
Actuellement (+1h)
En 1h, XiaomiHome (avec les mêmes équipements d’installés) a consommé 4k qu’il n’a pas restitués. Il n’y a pas photo
Fail2ban est opérationnel ?
J’ai fais un screen et je check tout a l’heure où demain.
Voici actuellement
Donc pour moi Xiaomi home, broad link, SMS et tahomalocalapi en python.
PS : punaise home bridge et ttscast ça tute rien qua eux 2!
Non malheureusement fail2ban ne fonctionne pas avec cette version de Python. J’ai fouillé mais je n’ai pas trouvé de solution, mais il faut dire que mes compétences sous cet OS sont proches de 0.
Aïe…
A défaut de faire quelque chose de suite je vais au moins cerner qui bouffe quoi est c’est une bonne chose.
Je regrette un peu mon passage a debian 11 mais bon plus de support en juin sur Debian 10.
Je suis surpris que ça râle vraiment pas plus que ça sur le forum car ce cas doit être quand même très fréquent.
Pour fail2ban c’est « simple » (en fait non…), fail2ban a sa propre version de python: /usr/bin/fail2ban-python.
On supprime le lien:
# rm /usr/bin/fail2ban-python
On met un lien vers la version système :
# ln -s /usr/bin/python3.9 /usr/bin/fail2ban-python
MAIS (il y a toujours un mais), pour une raison que j’ignore, bien qu’on a un /usr/bin/fail2ban-python, fail2ban utilise python3…
Attention, ce qui va suivre et super crade ! Ca casse complètement la cohérence des paquets debian et c’est mal !
Donc, il faut ouvrir /usr/bin/fail2ban-client, /usr/bin/fail2ban-regex, /usr/bin/fail2ban-server, /usr/bin/fail2ban-testcases et remplacer :
#!/usr/bin/python3
par
#!/usr/bin/fail2ban-python
Trop funky pour mettre ça en prod lol mais merci
Hello
Résultats ce matin.
+150 Mo pour Xiaomi
+17 Mo pour Tahoma
+16 Mo pour broadlink
+6 Mo pour sms
Clairement la fuite memoire majeure est sur ce plugin
Plus trop maintenu en plus. Je regarde à le remplacer par du MQTT…
Je regardais aussi pour migrer cela mais j’ai 2 élements dont je suis fortement dépendant à savoir la gateway xiaomi que j’utilise comme indicateur d’alarme avec l’anneau et le son pour ma sonnette. (y’a un client mqtt mais plus maintenu et pas sur de pouvoir utiliser le son de la gateway : GitHub - cflurin/xiaomi-mqtt: A Bridge between the Xiaomi Mi Smart Home Gateway and the Mqtt broker.)
Egalement mon robot aspirateur xiaomi STYJ02YM (xiaomi v1). Il est plutot en fin de vie (déjà plus de 4 ans), fait des siennes par moment mais bon il fait encore le taf. C’etait facile avec le plugin je peux me lancer avec Valutedo Getting Started | Valetudo mais je sens que je vais cramer pas mal d’energie, peut etre que quelqu’un me dira le contraire)
Si je sais shoot ca, bye bye
PS : ou je restart ma vm homeassistant qui dort pour faire office de relai mqtt sur ces fonctions (j’adore jeedom mais la reactivité et compatibilité de HA semble incomparable)
Bonjour,
Inutile d’incriminer un quelconque plugin, la fuite mémoire est dans python 3.9.2 installé par Debian 11.
Tous les programmes de l’OS ( ie fail2ban) ou les plugins Jeedom utilisant les fonctions de Python 3.9 qui fuient, ont une consommation mémoire en augmentation permanente, avec comme conséquence, la réduction du swap disponible.
La conso mémoire du daemon rfxcom:
Il manque l’avis de Jeedom sur les fuites mémoire de python 3.9.2 . Comment contourner ?
Faudrait-il que tous les plugins embarquent leur propre version de python corrigé ? Ca serait beaucoup de travail des devs de plugins pour une Debian 11 en oldstable.
Dans Debian 12, il y a peut-être d’autres fuites mémoire dans la version de python embarquée. 
Homebridge charge en fonction des événements qu’on lui envoi… donc beaucoup d’événements = beaucoup de charge cpu.
(Quand on dit beaucoup c’est jamais énorme non plus, mysql chargera plus vite que Homebridge par exemple)
Pour ce qui est de la mémoire, directement lié au nombre d’équipements. Et aucun memory leak signalé sur leur github depuis bien longtemps. (De mon côté j’ai fait des tests de memory leak sur mon plugin et rien constaté ou mis en place des correctifs par le passé pour les résoudre)
Le travail est déjà fait et réutilisable par tous. C’est hyper simple à l’utilisation et règle aussi la compatibilité debian12.
Il suffit d’une dizaine de lignes de codes à changer.
Je ferai un post à ce propos après mes congés si ca intéresse du monde.
Grave, je pense qu’on serait tous preneur
En attendant je surveille tous les consommateurs de mémoire en historique dans jeedom pour automatiser mes redémarrages de demon que quand necessaire
Oui enfin c’est surtout les devs de plugins qui doivent être intéressés car les modifs dont je parle sont à faire de leur côté 
