Cela fait un moment que je constate une augmentation constante de la RAM sur mon Jeedom et je ne parviens pas a trouver la cause de ce probleme tres embetant (depuis des mois …).
J’ai bien entendu suivi les conseils en desactivant plugin apres plugin pour voir 'evolution mais ca ne change pas grand chose, en desactivant un plugin ca libere un peu de RAM mais ne corrige pas le fond du probleme.
Page sante OK (les plugins pas a jour c’est juste ceux qui sont en preparation pour Jeedom 4.4):
Mysqld : les donnees SQL ne sont-elles pas enregistrees sur l’EMMC ?
Comment identifier ce qui fourni tant de donnees?
Le plugin Zigbee : stopper le deamon et le relancer remet la conso de memoire a beaucoup plus bas mais ca augmente a nouveau dans le temps. Que faire?
Le plugin Zwave : il consomme pas mal de memoire mais n’augmente pas tant que ca dans le temps. Je ne souhaite pas migrer vers le nouveau plugin pour le moment. La cause de mon soucis n’est pas la.
JeeCron.php : la il y a une tres forte augmentation dans le temps… qu’est ce que JeeCron.php gere? Les scenarios? Ceux execute a 1 minutes ou tous? Comment puis-je identifier lequel peu engendrer une telle augmentation / fuite de memoire ?
Le plugin AlexaAPI : il consomme pas mal de memoire mais n’augmente pas dans le temps. N’est donc pas le source du probleme.
Pour moi MySQL, Zigbee et JeeCron sont les causes de l’augmentation constante de la consommation de la memoire.
J’apprecierai vraiment de l’aide pour resoudre ce probleme car je ne sais pas par ou commencer.
Swapiness → 100% ???
commencer par le mettre à 10%
Ensuite mettre TOUS tes plugins, certains sont connus pour avoir des fuites memoires
Les bases de données travaillent en memoire et ecrivent de temps en temps sur disque → Normal
Du coup, tu as une explication … Que faire : migrer vers jeezigbee
→ l’augmentation de la mémoire est un phénomène NORMAL, le systeme gère ceci très bien et tant qu’il a de la place en mémoire, il ne decharge pas ce que ne sert pas.
C’est une saturation qui n’est pas normal. En l’état, dans ton graph, pas de saturation
Bonjour,
Linux optimise son fonctionnement en utilisant beaucoup ma RAM.
De fait, au bout d’un certain temps, tu as la RAM qui est quasi toute utilisée, mais c’est un fonctionnement normal, c’est la partie cache de la mémoire.
Si un process a besoin de plus de RAM, il va libérer du cache et l’utiliser pour lui.
Merci pour vos reponses mais juste pour info j’ai un second Jeedom qui effectivement a moins de choses qui tournent dessus et la RAM est stable a 75% depuis des mois.
Sur mon Jeedom principal, la RAM continue de descendre jusqu’au plantage (dumoins j’avais remarque ca il y a quelques mois / voir annees)
Je vais donc laisser mon Jeedom principal en l’etat et voir si effectivement il ne crache pas / plus.
Desole, je ne viens pas du monde Linux … sur des serveurs MS si je vois ca je ne suis pas rassure
Bonjour,
Je comprends pas trop, as tu des soucis ? Car la le graph est normal la, il y a de la rom libre il s’en sert je vois pas de soucis la dessus c’est le principe de Linux on ne libère que si besoin.
En fait avant la Atlas j’avais un Odroid qui hergeait Jeedom et j’avais ce probleme de consommation de memoire et arrive a environ 30% j’avais un plantage de Jeedom, plus rien d’accessible.
J’ai migre vers la Atlas depuis des mois deja (depuis sa sortie en fait) et je constate toujours ce probleme de consommation de memoire … et desormais je reboot Jeedom avant d’atteindre ces 30% juste par crainte.
Comme dis je ne viens pas du monde linux, je ne fais que constater et le dire ici.
Je vais laisser Jeedom sans rebooter meme s’il descend sous les 30%, je verrais bien.
C’est vous les experts, si vous dites que tout semble normal et qu’une telle courbe est normale alors ok pas de soucis je vous crois bien entendu
Bonjour
C’est toujours normal pour la mémoire moins pour la swap. Ce qui consomme beaucoup c’est mariadb ça tu ne peux rien y faire ça dépend de ce que tu demandes à ton jeedom et le plugin zigbee qui est obsolète migrer sur jeezigbee serait pas mal.
Bon, meme avec le plugin ZigBee désactivé ça continue …
Je récupère un peu de mémoire suite à la désactivation du plugin mais la chute se poursuit et le swap est toujours autant utilisé.
Dans ce cas essaye de désactiver les plugins jusqu’à trouver le coupable et si tu en trouve pas c’est que tu demande trop de truc à la box pour sa capacité
Ok … pas cool mais bon va falloir que je passe du temp pour voir comme tu dis ce que je lui demande de trop.
Je ne sais pas comment évaluer ça dans Linux…
Bref je retourne à la case départ.
Rien à faire dans Linux tu coupes tous les plugins redémarre attend si la mémoire augmente c’est une une utilisation trop grosse de jeedom pour la capacité hardware sinon tu réactive les plugin a un un en regardant la mémoire au bout de quelques heures jusqu’à trouver le coupable
Effectivement j’en vois beaucoup aussi des sujets à ce propos…
Le problème c’est de savoir comment identifier la cause et ça c’est juste très difficile !
Surveillance processus, mémoire, etc … ça ne suffit pas à déterminer où sont les limites hardware de ces box hébergeant Jeedom.
Linux ne gère-t-il finalement pas si bien que ça les resources système ?
Moi j’y comprends plus rien… alors j’arrête processus / plugins / scénarios les un après les autres mais rien n’indique un lien spécifique à ce problème de performance et je crois que c’est comme le dis Loïc que le système est peut être simplement surchargé.
Bref c’est pas gagné.
En comparaison, j’ai une Atlas avec 42 plugins, 194 scénarios, 4776 commandes et….
Je suis entre 0,28 et 0,33 sur une journée !
Sur une smart avec JeeZigbee et quelque appareils + JeeLink, je dépasse jamais les 0,15, et la moyenne sur une journée est à 0,08 …
Bref avoir un CPU a 2/3/4 c’est gigantesque !
(Sachant que 2 veut dire 200% = processeur sous l’eau / il est utilisé au double de ses capacités)
Bref 2 : ton pb n’est peut être pas la mémoire, mais un truc qui utilise le processeur bien plus qu’il ne peut !
Comme dit loic, tu desactives tout.
Tu redémarres, attends 15 minutes (le processeur 15 minutes doit rester en desous de 0,1), tu actives UN plugin, attends 15 min, etc, et tu va trouver le coupable car il y en a un….
Tu pourrais noter dans quel ordre tu actives quoi, puis comparer avec l’historique.
ta charge CPU
pas CPU, juste charge (système) => une valeur haute peut être due à la mémoire, le stockage, réseau … c’est juste un signe que des process attentent une ressource
