Si ca peut aider, après un peu plus d’un jour de test, voici les résultats suite à la suppression du plugin Zwave et au changement de config proposé. Je ne me focalise ici que sur la mémoire disponible, en ce qui concerne le swap, il vient juste de baisser très légèrement ce matin (99.7%), ce qui ne me parait pas illogique puisque la mémoire disponible a chuté.
Ce qui me désole, c’est que finalement après ces modifs, l’utilisation de la mémoire n’a pas diminué, que du contraire. Mais on ne se décourage pas 
Je ne le dis sans doute pas assez dans de nombreux posts … C’EST NORMAL ET CE N’EST PAS UN DISFONCTIONNEMENT d’avoir un usage de la mémoire qui augmente sans cesse
Linux foncitonne comme ca, il souhaite utiliser toute la mémoire dispo donc il est normal que la mémoire dispo baisse. Il faut juste savoir détecter la bonne et la mauvaise baisse de mémoire (c’est comme les bons et les mauvais chasseurs) !
La bonne diminution est souvent plutôt asymptotique, la mauvaise plutôt linéaire, mais c’est à analyser sur plusieurs jours
En l’état, si ton swap n’a pas diminué depuis 2 jours, et que tu tournes autour de 40-50% de mémoire dispo, je ne vois strictement rien d’anormal
Norbert
ce n’est pas seulement l’utilisation de la mémoire totale qu’il faut regarder.
Avoir un process qui consomme sans cesse plus de mémoire et qui ne la libère jamais, ce n’est pas normal, c’est le signe du fuite de mémoire potentielle.
1 « J'aime »
Bonjour,
Malheureusement j’ai difficile à me résoudre à cette explication.
Pourquoi ?
Avec mon ancien EMMC de 8G, j’ai laissé tourner jeedom pendant de nombreux mois sans jamais m’inquiéter de rien, je n’y touchais pas et tout fonctionnait bien.
Ensuite après avoir repris l’écriture de quelques nouveaux scénarios, je me suis dit qu’avec un EMMC de 8G, je finirais un jour par tomber à cours de mémoire disque, qu’avec les années l’emmc commençait peut être à se fatiguer et que avant que la smart ne soit plus supportée, c’était peut être le bon moment de faire un petit investissement dans un emmc 16G, vendu tout prêt à installer par Domadoo.
C’est donc en changeant l’EMMC que je suis passé à debian 11 et que j’ai du mettre à jours quelques vieux plugins.
Sauf que, suite à cet upgrade, j’ai constaté que:
- Je devais refaire le cookie Alexa tous les 10 jours (je ne devais pas faire cela avant)
- Au bout d’un certain temps, certains scénarios semblaient cafouiller un peu et quand j’allais sur la page santé, j’avais des « Mémoire suffisante » en rouge et >0 et finalement, je devais rebooter toutes les semaines.
Est-ce que ces deux points constatés sont liés au passage debian 11? Je n’en sais rien.
Depuis, il est vrai que beaucoup se focalisent sur l’utilisation mémoire, peut être un peu parano, mais il me semble quand même que la gestion est perfectible.
Et les scénarios qui surveillent l’état mémoire et redémarrent des plugins pour libérer de la mémoire, c’est cela que j’appelle des rustines, car si chez moi c’est bien utile, je constate que cela ne permet que de gagner du temps, cela ne semble pas tout résoudre et je ne pense pas pouvoir encore rester plusieurs mois sans redémarrer jeedom.
En ce qui concerna le swap, là encore dans un soucis de fiabilité à long terme, pour préserver l’emmc, j’aurais préféré que le système utilise le disque le moins possible, c’est à dire en dernier recours. Un swap qui monte et qui descend alors que l’on a encore de la ram disponible, je trouve ca un peu dommage.
Après, j’avoue être de la vielle école et habitué aux automates qui tournent h24 sans jamais être redémarrés, je suis probablement trop perfectionniste.
Car, étant donné que l’on peut automatiser tout cela, est-ce dramatique de devoir redémarrer des plugins tous les deux trois jours et éventuellement la box complète toutes les semaines ?
Nous avons des systèmes de plus en plus complexes et il ne faut pas se leurrer, la fiabilité absolue n’existe pas, l’important est qu’en cas de problème on puisse redémarrer correctement.
Cordialement,
Philippe
1 « J'aime »
Sur ce point, si tu as appliqué les preco, ca devrait régler le pb de swap. Tu ne devrais plus avoir de mémoire insuffisante.
Comme déjà dit, suivre l’évolution sur quelques jours/semaines (RAM + SWAP).
Ca ne devrait donc plus être le cas
Perso, le concours de celui qui a le plus long uptime me semble depassé. Je ne vois pas l’intérêt de na pas rebooter sa machine. Il ne faut pas le faire tous les jours, mais 1 fois par mois ne me semble pas deconnant non plus.
totalement d’accord, et un reboot de temps en temps permet aussi de s’assurer que tout redémarre bien. C’est un peu comme restaurer régulièrement ces saves sur un env de test pour s’assurer qu’elles sont bonnes
1 « J'aime »
Bonsoir,
Hier soir elle a commencé a dégringoler
et là : 67.6% en quelques heures
Point positif ; le swap est resté plus longtemps > 99%
Mais il va falloir que je regarde plus en détail ; je viens de remarquer que le swap commence a descendre toujours autour de 22h …
De mon côté, un peu tôt pour vraiment pouvoir gauger le gain après les modifs mais la descente du swap est toujours présente après quelques jours.
Le monitoring indique que la ram n’est jamais descendue en dessous de 40%
Que donne ?
sudo journalctl --disk-usage
laissez tourner !
éventuellement, mettez une sonde pour détecter des pbs mémoire via ssh mamanger :
dmesg | grep -i oom | wc -l
info numérique historisée, rafraichit toutes les 5 ou 10 min, et notif si c’est supérieur à 0
Dans l’attente, pas de reboot, pas de kill de process
POUR RAPPEL x10, l’utilisation de la RAM et du SWAP est normale dans 99% des cas
Bonjour,
Voici:
Suite aux différents commentaires, j’ai aussi lancé la commande htop et trié par utilisation mémoire
Voici chez moi les plus gros consommateurs de mémoire.(copies d’écrans bout à bout), je ne sais pas si cela peut en inspirer certains.
A savoir que de mon côté, j’ai fais un gros nettoyage, supprimé le plugin zwave, supprimé pratiquement toutes mes historisations, j’ai essayé d’alléger tant que je pouvais, et c’est vrai que la mémoire diminue moins vite. La BD ne fait plus que 19 MB et mes backups journaliers (sur mon syno) sont passés de 120 MB à 97 MB.
Parmis les plugins les plus consommateurs de mémoire, je pense avoir identifié sur mon système:
- Le plugin broadcom
- Le plugin alexa.
Le plugin broadcom, je l’utilise peu et je le redémarre automatiquement si le swap est trop bas. → je pourrais le désactiver systématiquement la nuit et le redémarrer au matin, est-ce que ce serait mieux que d’attendre que le swap baisse pour le redémarrer ?
Le plugin alexa, j’ai tenté de le redémarrer et j’ai du regénérer le cookie amazon, donc, je n’y touche plus. Idem si je redémarre jeedom, je dois regénérer le cookie 
Et ce plugin alexa à déjà défrayé la chronique sur la communauté. Je l’utilise pour faire parler alexa afin de confirmer le mode d’activation de mon alarme, mais il ne fonctionne (pas) plus correctement: la fonction « faire parler alexa » de temps en temps ne fonctionne pas et ce, sans raison apparente. J’ai lu qu’il existait une version premium payante mais uniquement en beta et avec comme commentaire: ne pas télécharger la beta ?! Mais je n’ai trouvé aucune info et aucun retour rassurant là dessus.
Voilà, je ne sais pas si ces infos pourront aider la communauté, mon système tourne maintenant depuis 7 jours et il me reste 55% de swap 
Je pense que je vais essayer de ne plus toucher à rien et de voir si j’arrive à passer le cap de 2025
Rien à faire de ce coté là, c’est parfait comme ca
Regarde ici … une correction sur le plugin a été faite par @Mips : Mémoire qui baisse progressivement depuis 4.4 ou Debian 11 - #78 par Mips
Installe la beta de broadlink, ca devrait regler ce pb.
Norbert
1 « J'aime »
broadcom ou broadlink? je ne connais pas de plugin broadcom
Oups, c’est bien broadlink.
Plugin en version béta installé. Le swap est remonté de 54 à 60%, la mémoire disponible de 40 à 49%.
Merci
Bonjour,
Est-ce que la version beta de broadlink va passer en stable ?
Merci,
1 « J'aime »
Bonjour à tous,
Ce matin JEEDOM a complétement planté. Sans surprise c’était le swap qui était a zéro depuis on bon moment.
Le problème a toujours persisté malgré les solution apporté en début de poste. Mais les chute a été fortement ralentit. Dernièrement j’ai relancé le plugin Broadlink dont je n’en avais pas l’utilité au par avant.
Je vais également installé la beta du plugin Broadlink est surveillé l’état de swap de libre.
Ca peut être un autre plugin aussi, tu as quoi comme plugin en mémoire ?
Pour ma part j’ai fait un scenario « Reboot crash » qui se déclenche quand le monitoring me dit :
#[Énergie][Pi3b+][Swap Libre (Pourcent)]# < 18
et qui me prévient par mail et reboot Jeedom.
Ca marchait bien mais ces reboot m’agaçaient donc ensuite, j’ai ajouté un autre scenario « Daemon restart » qui relançait chaque nuit les daemon des plugins en faute pour éviter de vider le swap.
Ca marchait très bien et plus de reboot ! Et puis finalement j’ai trouvé diverses corrections sur ce forum pour les plugins et vu que je n’ai plus de fuites mémoires j’ai désactivé « Daemon restart » mais gardé « Reboot crash » au cas où. 
plugin-broadlink est passé en stable aujourd’hui
3 « J'aime »
Bonjour,
Alors je ne sais pas si c’est lié, mais le 15 mars, comme jeedom me le proposait, j’ai fait une mise à jour du plugin Broadlink, j’ai bien la version du 28/02/25.
Mais 5 jours plus tard, la mémoire disponible était descendue à 26% alors qu’elle restait toujours > à 50% avant cette mise à jour, aussi le swap était tombé à 18%, ce qui était de mauvais présage.
Comme je n’étais pas à la maison je ne voulais pas planter mon jeedom donc je n’ai pas osé trop expérimenter. J’ai toutefois essayé de redémarrer le plugin Broadlink mais cela n’a rien amélioré, alors j’ai du me résoudre à redémarrer le Jeedom à distance, heureusement tout s’est bien passé.
Depuis que j’avais installé la version Beta, je n’avais plus eu de problème de fuite de mémoire, est-ce que ce problème serait du à la mise à jour du plugin ? Est-ce que quelque chose se serait mal passé ? Aussi, j’ai toujours le flag « Beta » qui apparait, est-ce que je dois changer quelque chose dans ma config ?
Merci d’avance.
