parce que cette affirmation est fausse.
aucun problème avec aucun de mes plugins ayant un démon python;
autre exemple plugin-rfxcom, plugin-sonos3 sont en python et pas de soucis.
OK.
Moi ceux qui posent problème:
- xiaomihome
- broadlink
- teleinfo
Et du coup ça veut dire que les developpeurs peuvent appliquer des correctifs?
Et aussi, pourquoi le passage en Python 3.9.19 corrige le soucis?
Note: je n’utilise pas tes plugins @Mips du coup je ne peux pas comparer.
Pour celui là je doute, je l’utilise et je ne constate pas de perte de mémoire ni de swap.
Et pourtant ce Jeedom tourne depuis 121j et quelque.
1 « J'aime »
Bonjour,
Si si je confirme, dés qu’on relance ce demon le swap remonte.
Mais pour le coup, c’est variable et je n’ai jamais le même résultat. J’essayais de trouver des corrélations ou autre piste avant de réagir aux messages, mais je ne trouve rien de flagrant.
Il y a qq jours mon swap est passé en rouge, ce qui arrive régulièrement depuis debian 11 et le passage en 4.4 sans que je puisse dire à mon niveau lequel est impactant.
Je relance uniquement teleinfo et je remonte à 35% instantanément.
Odroid N2+ 4Go
Jeedom 4.4.19
Debian 11 mis à jour régulièrement.
Donc oui on a depuis un certain temps un problème, moi je n’ai pas le niveau d’analyse mais ceux qui l’on devrait se regrouper pour échanger leurs idées et diagnostics et formuler les bonnes pratiques pour les plugins. A priori Mips n’a pas de problème avec ses plugins, sans doute à t’il ces bonnes pratiques et habitudes de développement qu’il faudrait divulguer.
Bien cordialement
1 « J'aime »
Chez moi j’ai réussi a résoudre le problème en supprimant le plug in xiaomi mais j’avais fait aussi un bloc code qui fonctionnait bien pour rebooter les démons une fois par jour.
plugin::byId('xiaomihome')->deamon_start(true);
plugin::byId('teleinfo')->deamon_start(true);
C’est exactement ce que je fais… redémarrage des deamons des plugins concernés.
Et j’approuve ce que propose @rennais35000 , il faudrait que tous les développeurs utilisant Python aient les bonnes pratiques afin de résoudre ces soucis qu’on peut qualifier de global !
Avec l’aide de @Mips et en partageant ses méthodes ça pourra aider les autres.
Je n’ai non plus assez d’expérience pour aider ici, j’essaye de lire les posts ici et là pour aumoins mettre en place une solution temporaire qui évite de faire planter Jeedom…
Les 2 dernière personnes que j’ai aidé sur des pbs mémoire/swap avaient des pbs qui n’avaient rien à voir avec celà. La mémoire était juste une conséquence.
Créez un nouveau sujet et mettez la page santé… Déjà demandé plus haut pour qu’on puisse avancer
Norbert
Bonjour,
Il l’a déjà fait, sur la partie de community réservé aux développeurs.
Tout est détaillé pour la mise en œuvre. Exemple concret : le plugin RFXCOM fonctionne maintenant avec les bonnes pratiques et ne souffre plus de fuite de mémoire.
2 « J'aime »
Et donc c’est à la volonté des devs de mettre en place ces corrections (ou pas).
Hum …
@ngrataloup , je te mets une copie de ma page santé dans un autre sujet …
Le problème est plus complexe que cela;
effectivement mes démons n’ont pas de soucis mais je n’utilise pas la même base que la plupart; ce qui me fait dire depuis le début que le soucis vient d’un bout de code ou d’une lib utilisée dans le template python du plugin template fourni par jeedom qu’en toute logique beaucoup de devs utilisent (moi y compris avant de revoir cette approche);
et « ma » solution n’est pas « l’unique » solution ni même la meilleur (ou peut-être si, ou pas, pas de jugement 
ironie inside)
bref… vu que je préfère travailler sur un truc qui apporte plus de valeur que débattre sur « ancien/nouveau » et pour plus que 8 personnes… - ok j’aurai pas du la faire celle-là, trop tard -, j’ai relancé mes recherches en me tournant cette fois sur la class Queue car c’est une des seules que je n’utilise pas et … ca parait qd meme un bon candidat pour un memory leak 
et bingo: Queue.get() memory leak · Issue #88077 · python/cpython · GitHub (pour la petite histoire c’est plus un memory fragmentation qu’un memory leak mais on va passer les détails)
j’ai pu reproduire le problème dans un petit script de test et en plus le résoudre (toujours dans un script de test) 
N’ayant plus de plugin utilisant python autre que les miens (qui fonctionnent très bien) ou officiels que j’ai déjà fixé, il va me falloir un cobaye, de préférence ayant le plugin-broadlink (ou un autre officiel) pour autant que perte mémoire soit constaté.
Je souhaite tester le patch en direct sur sa box histoire de voir si ca permet de régler le problème sur un cas réel aussi, avant que je ne patch la version beta;
pas envie de patch à l’aveugle et après avoir un utilisateur qui se plaint que c’est pas sérieux car on fait que de la merde à livrer des trucs sans tester… (bah oui, c’est les réactions des utilisateurs qui font fuir les dev de ce forum! - celle là aussi j’aurais p-e dû la garder pour moi? 
…)
si quelqu’un est intéressé, je voudrais aussi qu’avant ça, si pas déjà le cas, la mémoire du process soit récupéré dans une commande script & historisée pour pouvoir se baser sur un constat objectif qu’il y avait fuite mémoire et que éventuellement il n’y a plus après patch.
8 « J'aime »
Honnêtement je je vois pas quoi y faire s’il y a qq chose a faire
Pour essayer de contourner le pb j’ai utilisé pyenv avec un version python plus récente dans le plugin en version bêta mais ce n’est sans doute pas une solution idéale
Bonsoir Noyax,
Je compatis tellement à vos problèmes de dev en plus des aléas de votre vie personnelle que je n’avais pas posté sur ces pbs. Je gérais manuellement en surveillant et en attendant patiemment, conscient que vous faisiez de votre mieux pour trouver une solution.
Vous ne tirez aucun avantage de vos développements et comme le dit Mips il est facile et injuste de dire qu’il ne se passe rien.
Dans un autre post, tu avais toi même répondu à Mips que tu allais regarder de ton coté car toi aussi tu avais vu cette baisse de mémoire sur ta propre installation teleinfo et la remontée en relançant le demon.
Te dire quoi faire je n’en sais fichtrement rien, sinon ce serait avec plaisir que j’apporterais ma contribution. Tu sais bien qu’à part tester, je ne suis pas bon à grand chose.
Comme j’avais lu que ses plugins étaient « propres » sur cet aspect j’espérais que ce serait reproductible dans vos codes car honnêtement il y a quand même beaucoup de posts qui parlent de fuite de mémoire depuis quelques temps et pas que sur ton plugin rassures toi.
3 ou 5 % par ci et par là ça finit par se voir.
Alors on peu ignorer le pb et faire des vœux. Je veux bien croire qu’on aient un pb de réglage comme le suggère ngrataloup et j’ai confiance en ce qu’il dit et sur ses compétences pour le dire.
Mais si c’est le cas, il y a bien quelque chose qui a changé car en ce qui me concerne je n’ai changé aucun réglage système ou Jeedom depuis ma migration en V11 et en premier lieu et core 4.4 ensuite. Hors je n’avais aucun pb de ce genre avant.
Peut-être que les réglages par défaut à l’installation de debian 11 ne sont pas adaptés, mais on ne peu pas toucher au système sans s’y connaitre. Si on me donne des préconisations, j’appliquerais mais je n’ai rien vu de tel.
Iperenna semble ne pas avoir de pb et son jeedom tourne depuis 121 jours, mais sans doute n’a t’il pas fais de mise à jour du plugin car ta dernière stable est du 21/08 et ça ne fait à date d’aujourd’hui que 108 jours dans le meilleur des cas sans avoir relancé le demon. Comme dit Mips dans un autre post « je n’aurais pas dû la faire celle là » 
Bien cordialement
1 « J'aime »
manifestement mon message n’était pas clair ou alors c’est mon humour qui n’est pas passé 
-
en tant que dev: si vous utilisez le template python fourni dans le plugin jeedom et que votre plugin manifeste une consommation mémoire en constante augmentation et vous voulez voir si on peut trouver une solution => faites vous connaitre pour qu’on puisse tester ensemble.
-
en tant qu’utilisateur: vous avez un plugin officiel avec démon python dont la consommation mémoire augmente constamment => faites vous connaitre que je puisse tester sur votre box si vous êtes d’accord de me laisser un accès.
comment connaitre l’utilisation mémoire?
- plugin script
- commande info/numérique
ps -eo rss,command --sort -size | grep id_du_plugin
exemple:ps -eo rss,command --sort -size | grep arlo- historisez la commande
5 « J'aime »
En effet je n’avais vu que la partie « en tant qu’utilisateur d’un plugin officiel »
Dès que je rentre à tome (moi aussi je m’essaie dans l’humour ) je regarde s’il y a une différence entre ma version stable avec venv et ma version bêta avec pyenv
Merci Mips pour ces infos,
J’ai une fuite de mémoire régulière sur mon installation, je surveillais ça de loin car j’ai un RPI4 avec 8 Go donc avec de la marge. J’ai mis en place la commande et je pense que la fuite chez moi vient du daemon siapro, j’essaie de valider ça (mon installation a rebooté par scénario cette nuit car ma mem est descendue sous les 50%) et j’en ferai part à @thanaus
Edit du 18/12: Ok, je confirme la consommation de mémoire en augmentation permanente sur le plugin plugin-siapro
J’ai une très bonne piste pour les plugins officiels et tous les plugins tiers dont le démon est basé sur le #plugin-template
exemple pour plugin-broadlink; encéphalogramme plat de la conso mémoire du démon:
une version beta sera dispo demain pour valider plus globalement et je prépare une mise à jour du #plugin-template pour les devs qui seraient intéressés.
l’auteur du plugin reste responsable de la mise à jour de son plugin, ca ne va pas se faire tout seul…
mais de quoi va-t-on parler sur community si ce n’est plus de conso de mémoire?
16 « J'aime »
Il reste tout de même les cookies de plugin-alexaapi pour s’occuper
11 « J'aime »
Ne faut-il pas parler d’ancienne et de nouvelle consommation des plugins 
1 « J'aime »
De debian 12, de version minimum et du core en 4.5 
1 « J'aime »