je n’aurais pas qualifié cela de « énorme »; on a déjà vu des captures d’utilisateurs ayant des valeurs de 50 à 100 => ca c’est énorme 
mais c’est à surveiller, en principe un jeedom ne devrait pas être autant chargé je pense; là on est d’accord
c’est probablement un signe qu’on arrive à la limite du matériel (mais donc pas forcément du cpu)
mais combien de coeur à sa box? si 4 ou plus, on est toujours juste en dessous de la limite
Oui exacte, j’ai une charge assez concequente due a des scenarios qui s’executent toutes les minutes, exemple à 12:30:00
ensuite ça revient a une charge acceptable:
donc si je cromprends bien il peut y avoir une relation entre charge CPU et memoire due à des scenarios trop gourmants?
Je comprends bien pour le CPU mais que fait la memoire la dedans? apres l’execution d’un scénario la mémoire devrait se libérer non?
Bonjour
Non car ton scénario a besoin d’informations de la base de données et la base de données même une fois fini garde tout en mémoire au cas où tu aies encore besoin et ne libérera la ram que si l’os lui demande (en gros j’ai simplifié)
J’ai revu tous mes scenarios et j’ai mis une frequence d’execution plus espacee, par exemple si un scenario s’execute toute les minutes, j’ai mis 5 minutes, etc …
Pour l’instant j’ai tous les plugins en fonction.
La charge CPU reste acceptable mais la degringolade de la RAM continue toujours, en 2 semaines c’est incroyable comme cela chute:
C’est pas clair cette histoire.
Je vais desactiver chaque plugin 1 a 1 et voir s’il y en a 1 qui pose soucis mais je crois deja avoir fait cela il y a quelques mois/annees et je n’ai jamais reussi a trouver ce qui provoque cette ‹ fuite de memoire ›
EDIT:
J’ai fais la mise a jour de tous les plugins & Jeedom a l’instant et la memoire est remontee a 69% !
Je capte plus rien…
A suivre.
Sebastien
Bonsoir
La mémoire libre n’est pas un bon indicateur.
Comment est ta charge système ?
(C’est le seul a regarder quand on est pas un pro, il a été inventé pour cela, avoir une idée générale du système pour les quidam comme nous)
Si inférieur à 40%, tout roule.
S’il s’approche ou dépasse les 100, c’est ennuyant.
Comme ça ne semble pas clair, je vais répéter ce qui a déjà été dit :
=> version courte : Linux utilise TOUTE la mémoire disponible. C’est normal, c’est attendu et c’est logique : pourquoi acheter de la RAM pour ne pas s’en servir ? Ce serait un gaspillage d’argent et de ressources naturelles majeur. Et une faute de la part des concepteurs du système d’exploitation.
=> version longue :
Il est compréhensible que voir Linux utiliser presque toute la RAM disponible puisse être inquiétant au premier abord, surtout si on n’est pas familier avec la manière dont les systèmes d’exploitation gèrent la mémoire. Mais pas de panique, c’est en fait une bonne chose.
La RAM (mémoire vive) est une ressource précieuse et rapide, beaucoup plus rapide que le disque dur ou le SSD, les cartes SD, eMMC. Linux, comme d’autres systèmes d’exploitation modernes, essaie d’utiliser cette mémoire efficacement pour accélérer les opérations. Voici les points clés à comprendre :
En résumé, voir Linux utiliser toute la RAM disponible n’est pas un signe de problème. C’est plutôt le signe d’un système qui travaille à maximiser ses ressources pour vous offrir la meilleure performance possible. Il est conçu pour être flexible et ajuster l’utilisation de la mémoire en fonction des besoins, assurant ainsi une expérience utilisateur fluide et réactive.
Dans la capture d’écran suivante, on peut voir l’utilisation de la mémoire d’un Jeedom doté de 8 Go de RAM (c’est beaucoup trop, même si j’ai une raison pour avoir mis en place cette configuration). Si j’affiche le même graphique que toi dans Jeedom, je verrai une courbe similaire à la tienne. On pourrait en déduire qu’il n’y a plus de RAM et que le système va planter. Pour autant, de la mémoire disponible, il y en a plein. Linux videra les caches dès que nécessaire. La mémoire réellement utilisée par Jeedom, grosso modo, c’est la zone s’affichant en vert.
Une explication détaillée de cette image donnerait quelque chose comme ceci :
Ce graphique représente l’utilisation de la mémoire sur un système Linux sur une période donnée, de vendredi soir à dimanche. Voici les éléments clés pour interpréter ce graphique :
Les valeurs en bas du graphique montrent les statistiques courantes (Cur), minimales (Min), moyennes (Avg) et maximales (Max) pour chaque catégorie sur la période représentée.
Le graphique montre une utilisation stable de la mémoire avec une légère tendance à la hausse sur la période observée, ce qui peut être normal en fonction des applications et des services s’exécutant sur le système. Le système ne semble pas saturé, car il y a encore de la mémoire « unused » (inutilisée) et la quantité de swap utilisée est faible, ce qui indique que le système n’a pas besoin de recourir excessivement à la mémoire virtuelle, ce qui ralentirait les performances.
Il est également important de noter que le graphique inclut les mémoires tampon et le cache comme de la mémoire utilisée, alors qu’en réalité, cette mémoire peut être libérée si des applications en ont besoin, ce qui est une stratégie d’optimisation courante dans les systèmes Linux.
Et pour finir, une charge CPU (load average) de 3 sur une machine dotée de 6 coeurs n’est absolument pas inquiétant. Le CPU est loin d’être saturé.
Sur un système tel l’Atalas (dotée d’un CPU à 6 cœurs), un « load average » de 3 signifie que, en moyenne, la moitié des cœurs du CPU sont utilisés. Un « load average » de 1.0 signifie que l’ensemble des cœurs est chargé à 100 % (en considérant que le CPU n’a qu’un seul cœur), donc avec un CPU à 6 cœurs, un « load average » jusqu’à 6.0 signifierait que la machine est à pleine capacité (sans compter le multithreading, si disponible et applicable).
Un « load average » de 3 n’est donc pas particulièrement inquiétant, surtout si les processus sont optimisés pour le multitâche. Cela indique que le système est utilisé, mais qu’il a encore de la capacité de traitement disponible. Pour un serveur web ou une application qui gère beaucoup de petites tâches concurrentes, un « load average » légèrement supérieur au nombre de cœurs peut ne pas être inquiétant.
Bref, en conclusion cette machine ne semble absolument pas en difficulté. Quant au titre, il est erroné. On n’est pas du tout dans le cadre d’une fuite mémoire. Une fuite mémoire, c’est ça : Wikipedia - Fuite mémoire.
Tu as optimisé tes scenarios, tu obtiens le résultat que tu souhaites, le système d’exploitation ne plante pas, Linux (le noyau) ne se met pas à tuer des programmes pour protéger l’OS, ce qui rendrait Jeedom inutilisable ? Donc tout va bien. Jette un œil de temps en temps, mais tant que tout fonctionne, tout va bien
Quand tu mets à jour les plugins, les deamons redémarrent.
C’est peu être le signe que c’est un des ces plugins qui te posait problème.
Cf longue explication de @pommedapi …
A première vue, il n’y a pas de PB et oui, il est normal de récupérer de la ram si on redémarre les process. mais ça ne veut absolument pas dire qu’il y a un pb.
Le graphique mémoire montre une tendance asymptotique, ce qui est un fonctionnement NORMAL d’un système linux
Norbert
Merci encore une fois pour vos explications que je comprends.
Ma seule crainte c’est que Jeedom se plante (encore) et il faudra alors bien admettre que c’est bien lie aux performances…
Voici le monitoring des performances, on voit bien encore la RAM qui baisse (mais bon c’est apparement normale), la charge CPU acceptable pour une Atlas et aussi un swap qui grimpe.
Bref, je ne touche plus et je reviens des que ca crashe.
Sebastien
Bonjour,
Et MERCI pour tes réponses très explicatives.
Je rencontre un problème qui ne semble pas être décrit dans tes réponses.
Pi4 4Go, SSD mSATA, SWAP : 2048, Jeedom 4.3.23 stable
Je ne consomme pas de RAM et je consomme du SWAP, tous les jours un peu plus. Je n’arrive pas à trouver d’explication.
Si je retourne sur Raspberry Pi OS Buster 64 bits sur la même machine, je ne consomme plus du tout de Swap et 1 Go sur la RAM en moyenne
De retour sur Raspberry Pi OS Bullseye 64 bits, la machine consomme du Swap alors que la mémoire RAM ne semble pas être sollicité (c’est ma configuration par défaut, prod).
J’ai remarqué, mais cela ne veut certainement rien dire, que si j’arrête le plugin RFXCom et ZwaveJS, cela libère instantanément du Swap.
Graphe montrant l’usage de la RAM et du Swap, pas de pic de CPU en dehors du passages des CRON.
J’ai cette même sauvegarde, sur Jeedom Alpha 4.4.2, restaurée sur un Pi3B+ (1 Go de RAM) qui tourne sur Bullseye 32 bits qui ne consomme pas plus de 5 ou 10%
A la différence que cette machine n’a pas le Demon ON sur les plugins RFXCom et ZwaveJS (car je n’ai pas de dongle de test).
Je n’ai pas de scénario qui s’active tout le temps.
Ce qui m’étonne, c’est surtout le retour (que je ne veux pas) en Raspberry Pi OS Buster sur la même machine et le Swap est à 0.
Dans cette image, le reboot est trop proche, mais d’ici quelques jours, on y verra Python3, Node et MariaDB consommer du Swap
Preneur de toutes idées !
Merci
Edit :
Test que j’ai effectué :
Swapiness à 1 (c’est indiqué dans la FAQ de MariaDB) = cela swap quand même (pourtant je n’ai jamais vue la RAM passer sous les 70% en crête d’utilisation, mais rien ne prouve que cela n’est pas ce qui se passe en vraie
Désactivation du SWAP : La machine devient lente, à ne rien comprendre, même l’accès au terminal SSH est lent, la recherche des mises à jour de Jeedom aussi etc… a croire qu’il faut obligatoirement du SWAP.
Bonjour à tous,
La gestion de la mémoire est un sujet très complexe et comprendre d’où peut venir ton problème n’est pas du tout simple.
J’avoue ne pas connaître en détails cette box officielle de Jeedom mais je suis étonné de la valeur du swapiness à 100 qui indique à l’OS de toujours privilégier le SWAP à la mémoire.
Je pense qu’il y a une subtilité qu’il faudrait étudier.
Pour ma part, je désactive systématiquement le swap sur mes VMs. Je préfère de loin détecter au plus tôt un problème d’utilisation de la mémoire (fuite mémoire, charge supérieure à ce que peut fournir le hardware, …) qu’avoir un problème de performance en utilisant du disque en place de la mémoire.
De plus, utiliser du swap indique que la mémoire disponible n’est plus en adéquation avec l’utilisation du hardware et n’est qu’une solution temporaire à un instant T.
Comme indiqué dans les échanges, il ne faut pas regarder la mémoire libre mais la mémoire disponible.
Commande « top » :
Commande « free -m » :
Sur ces 2 captures d’écran, on pourrait penser qu’il n’y a plus que 6,5Go de libre sur 16Go de mémoire libre. Il y a en fait 13,5Go de libre sur les 16Go.
Linux a alloué à un instant 7,6Go de mémoire pour diverses raisons mais ne va les libérer si et seulement si un process lui demande de la mémoire.
Il faut donc aussi faire un monitoring de cette information et non pas uniquement la mémoire libre.
Dans ton cas précis, je désactiverai le swap (est-ce recommandé ou pas sur une atlas), un reboot pour être sur de bonne base et je ferai un monitoring de la mémoire disponible (et aussi de la mémoire libre vu qu’ils sont liés) et j’attendrai que l’OS utilise un mécanisme interne (oom-killer) pour voir si tu as un vrai soucis de mémoire. L’oom-killer est un mécanisme interne à Linux qui va supprimer un process le « plus gourmand » en mémoire afin de préserver l’OS
Si il n’y a aucun soucis, bingo… sinon il faudra investiguer plus en détails et activer un à un tous tes plugins jusqu’à avoir une idée de ce qui pourrait poser problème.
A ta disposition si tu souhaites plus de détails…
[EDIT] : je viens de supprimer le paragraphe concernant la coïncidence sur la mémoire libre après lecture du code de Jeedom. Le total indiqué sur la ligne « Mémoire disponible » n’est pas le total de mémoire disponible mais le total de mémoire sur la box.
La seule indication d’une utilisation excessive de la mémoire est donc un pourcentage basé sur la mémoire disponible (et non pas uniquement la mémoire libre).
Entre les 2 dates, on passe donc de 47% à 40% de mémoire disponible avec un swap disponible de 98% à 69%
Je t’encourage à suivre ce qu’a énoncé MasterChief. Je ferais de même.
Une réflexion supplémentaire tout de même. Si ce n’est pas un problème matériel (ce dont je doute, mais il faudra peut-être lever ce point), c’est un problème logiciel. La gestion de la RAM est du domaine de l’OS. Et donc, question, l’image ayant servie à installer la version problématique vient d’où ? Suivant les paramètres définis lors de la création de l’image, on peut avoir des réglages par défaut très différents d’une image à l’autre.
[edit] J’ai retrouvé un message que j’avais lu, mais pas sauvegardé sur le calcul de l’usage de la mémoire entre Debian 11 et 12 :
PSA: the way the “free” command calculates unused memory changed significantly between Bullseye and Bookworm
Une traduction possible serait :
« Bookworm [Debian 12] a mis à jour le paquet procps-ng, qui inclut la commande « free ». Une des choses qui a changé est que la façon dont la mémoire « inutilisée » est calculée inclut maintenant la mémoire partagée qui n’était pas comptée auparavant - rapport de bogue ici. Le résultat final est que Bookworm montrera une utilisation plus importante de la mémoire vive que Bullseye [Debian 11], même avec la même configuration. Cependant, comme le confirme l’inspection de /proc/meminfo, il n’y a pas eu de changement significatif dans l’utilisation de la mémoire vive.
Curieusement, Arch Linux utilise toujours la version obsolète de procps-ng. J’ai découvert cela en m’arrachant les cheveux en essayant de comprendre pourquoi Bullseye utilisait 85 mégaoctets de mémoire vive, alors que Bookworm en utilisait 200 mégaoctets. J’ai vérifié une installation d’Arch pour voir s’il s’agissait d’un changement dans le nouveau noyau Linux, mais Arch a indiqué 90 mégaoctets. Finalement, j’ai compris ce qui se passait, et si vous exécutez l’ancienne version de « free » sur Bookworm, elle indique 85 Mo (sur mon système ; le vôtre sera évidemment différent en fonction des modules du noyau). […] »
Attention à bien comparer des pommes avec des pommes et non des pommes et des carottes. Ce changement est particulièrement piégeux quand on n’est pas au courant.
Bonjour à tous et toutes!
Je reviens avec mes problèmes de fuites de mémoire et je pense avoir mis la main sur la cause du problème qui est en plus à 100% de ma faute.
Je fais beaucoup de gestion d’energie (électrictité) avec Jeedom et je gère de ce fait de la production solaire …
Au depart j’utilisai des scripts PHP dans un scénario pour lire les données de mes onduleurs SMA.
Puis j’ai fait un plugin SMA_SunnyBoy qui en gros utilisait les même script PHP pour la lecture des données des onduleurs SMA. Le plugin utilisait un CRON (1 minute d’interval pour le rafraichissement des données).
Finalement j’ai rajouté un Daemon PHP afin d’augmenter la fréquence de rafraichissement / lecture des données des onduleurs.
Depuis les scripts php dans un scénario (au départs), j’avais déja des ‹ fuites › de mémoire mais je ne pouvais pas clairement identifé que la cause était ces scripts …
D’ailleurs avec le plugin sans Daemon non plus …
Mais là en ayant rajouté un Daemon PHP, je vois que la mémoire associé à ce process ID du Daemon est la cause de la fuite de mémoire et dès lors que je désactive le plugin toute la mémoire se libère. Je peux alors réactiver le plugin et c’est reparti pour un temps jusqu’à ce qu’il y ait à nouveau saturation.
Bref, c’est mon foutu plugin qui en est la cause (ahh le nul)
Je vais de suite aller demander dans le forum des devs si quelqun peut inspecter mon plugin afin de voir où ce problème de fuite de mémoire peut être situé. J’ai essayé de trouver sans succès et je loupe forcement un truc certainement par manque de savoir/experience.
Merci,
Sébastien
Je salue le « mea-culpa » 
mais j’avoue que ca m’a fait un peu (beaucoup) sourire… « tout ça pour ça » 
, sans oublier qu’il n’y a que ceux qui ne font rien qui ne font pas d’erreurs 
Bonjour Sattaz,
As tu fini par trouver le soucis de fuite sur ton plugin SMA_SunnyBoy ?
Je suis en cours de recherche d’un soucis de fuite mémoire depuis le passage à debian 11 et je suis tombé sur ce post donc je vais voir si cela peut avoir un lien puisque j’utilise aussi ton plugin.
Ps: je n’avais pas de soucis de fuite avant debian 11 donc j’ai un doute sur le fait que ce soit ton plugin mais je vais checker pour être certain.
Merci
Bonjour.
Redémarrez le démon du plugin RFXCOM et regardez si une partie de la mémoire n’a pas été libérée, délivrée…
Salut,
J’ai mis en place un redémarrage automatique du deamon tous les jours à 2h du matin (c’est intégré au plugin).
Depuis la fuite de mémoire n’en est plus vraiment une car toute la mémoire consommée revient à la même valeur que le jour d’avant.
Mais avec tous les efforts fournis par les membres du forum des devs (merci encore!) on n’a pas réussi à trouver la cause.
Donc je laisse comme ça, c’est ‹ stable › …
Prends la version BETA sur le market pour le moment et dis moi si c’est ok pour toi… si c’est confirmé je passerai en version STABLE.
Edit : Plugin SMA_SunnyBoy publié en stable.
Merci,
Sébastien
Merci à vous ,
je fais la mise à jour de suite .
Je verrais ensuite avec le RFXCOM si jamais ca continue.
Bonne journée.
Bonjour,
Depuis que je suis passé en Debian 11 j’ai une diminution progressive de la mémoire de mon RPI4B. Tout les plugins sont à jour ainsi que Jeedom. La dernière màj du plugin RFXCom ne semble pas résoudre ce soucis (peut-être que ce n’est pas lui le responsable!)
Voici le détail:
Il semble que je suis loin d’être le seul avec ce problème
Merci pour votre aide/piste
Bonjour
Si tu as des Plugins python ça vient de la faut attendre qu’ils soient mis à jour seul le plugin rfxcom a reçu la correction
