je vais encore répéter ce qui a déjà été dit dans ce fil et sur de nombreux autres posts: que la ram augmente est normal et n’est pas un problème en soit, tant qu’il y a de la ram libre le système va la consommée au lieu de libérer celles qui est déjà prise donc il faut arrêter de se braquer la dessus.
j’entends que votre problème est une « instabilité » de la machine à un certain moment mais jusqu’ici on n’a pas beaucoup d’éléments.
Même si c’est le manque de ram qui provoque cela à un moment, ce n’est pas dit que ce que vous voyez maintenant est le problème.
Je m’incruste dans cette discussion car je rencontre un problème similaire (plateforme RPI3B+ 1 Mo).
Mon point de départ est effectivement une instabilité détectée par le plugin MQTT (pas le jMQTT) qui fait des alertes de perte de connexion (alors qu’il est en local).
A ce moment là je constate que la mémoire est à 7%. Je redémarre Jeedom, et tout revient à la normale.
J’ai le sentiment (mais c’est très suggestif) que ce pb c’est aggravé depuis les dernières mises à jour. Je m’explique: il n’y a pas si longtemps, j’étais encore en V3, et toutes les 2 semaines, je faisais un redémarrage de la box, pour ce même type de pb de perte de mémoire (mais à l’époque l’impact était sur l’exécution des scénarios la plupart du temps). Depuis que j’étais passé en V4, je n’avais plus ces problèmes, je n’avais plus besoin de redémarrer la box (je surveillais régulièrement la mémoire, vu que j’avais pris cette habitude…). Et là je dirais depuis 3 semaines, je rencontre de nouveau ces symptômes.
Ensuite ça peut aussi être du au fait que sur un système « frais » ça marche mieux et que là maintenant que ça fait plusieurs mois que j’ai fait migration V3=>V4 puis migration Debian9=>10 mon système n’est plus si « frais ».
En attendant la résolution du problème
la solution est de mettre en place un scenario qui régulièrement relance le demon.
je le fait toutes les 2 heures de mon coté.
// id du plugin
$_plugin_Id = 'jMQTT';
// charger le plugin
$_plugin = plugin::byId($_plugin_Id);
if (is_object($_plugin)) {
// start deamon ...
$scenario->setLog('démarrage du plugin ------->>> ' . $_plugin_Id);
$_plugin->deamon_start(true);
}
Je t’invite a signaler le problème ici
si c’est bien cela
afin que nos amis dev en soient informés.
Pas besoin de te signaler, on t’as vu
Par contre c’est étrange que même avec jmqtt désactivé tu constates quand même une augmentation de l’utilisation de la RAM.
Si ça résoud temporairement ton problème, ce serait bien d’augmenter l’amplitude des redémarrages jmqtt, par ex de toute les 2h à toutes les 8h ou tous les jours.
Hello,
Comme déjà dit par d’autres, l’augmentation progressive de ram est normale. C’est le fonctionnement de Linux.
Ce sont les plantages qui ne le sont pas.
Et du c’est vraiment jMQTT la cause (des plantages, pas de l’utilisation de la ram), c’est au niveau de son utilisation qu’il faut investiguer. Par e qu’on est nombreux à utiliser ce plugin sans soucis.
Merci pour ton retour, non ce n’est pas nécessaire de planter inutilement ton JEEDOM
Mais augmente un peu l’amplitude comme dit, normalement ce n’est pas nécessaire de faire plus d’un redémarrage par jour.
Je rebondis aussi sur le message de @fwehrle : @Sattaz, as-tu effectivement des plantages de jMQTT ? (Ou alors je n’ai pas bien compris ?)
Pour info, nous avons bien constaté une fuite mémoire dans une lib que nous utilisons, mais le remplacement de cette lib est compliqué, donc nous allons opter plus pour sa suppression (donc de tout le daemon PHP), et il faut du temps pour implémenter ça…
Donc si c’est stable avec le redémarrage du daemon, je te demanderai un peu de patience stp.
@Bad ,
OK, je vais passer la frequence de redemarrage du plugin a 1x par jour.
Note: le Jeedom sur lequel le plugin cause le probleme de RAM est sous 4.1.28 car je n’ai pas encore pris le temps de le passer en 4.2.x par manque de temps. Par contre j’ai un second Jeedom qui lui tourne sous sa derniere version et la je ne constate pas ce probleme de RAM alors que JMQTT y tourne aussi… comment est-ce possible?
Je me suis réjouis un peu trop vite.
Le problème jmqtt ne semble pas être la cause principale de la consommation de RAM sur mon Jeedom.
J’ai pourtant créé un deuxième Jeedom et j’y ai mis tous les scénarios les plus lourds et aussi certains plugin.
J’ai aussi arrêté des scénarios et plugin sur mon Jeedom principal où le problème de RAM existe mais rien n’y change.
Voyez le résultat, ça diminue effectivement plus ‹ doucement › mais ça ne résoud pas le problème:
@Bad , non j’ai désinstallé jmqtt de cette machine et je l’ai déporté/installé sur une autre.
J’utilise Jeedom Link pour passer les infos d’un Jeedom à un autre.
Est ce que tu peux regarder en redémarrant un des plugins qui est installé sur cette machine s’il y a un changement au niveau de l’usage mémoire ?
Redémarre en bien un seul (genre teleinfo, pas zwave qui à l’air de prendre le plus) et regarde.
J’ai le sentiment que ça va faire baisser l’utilisation de la RAM.
Au prochain coup ou la RAM monte, essayé d’en redémarrer un autre.
A ce moment-là, on aura plus la certitude qu’il y a un problème sur MySQL et pas un plugin particulier.
À côté de ça, ayant le PV chez moi aussi, je regarde pour te trouver des commandes de diag/débug sur MySQL.
Merci pour les conseils, je vais continuer mes investigations.
Et si c’est mysql, comment celà se réparer?
D’ailleur qu’est ce qui peut faire que mysql ne fonctionne pas correctement?
Edit: j’ai eu l’idée de redémarrer tous les démons de tous les plugin, pour voir si la RAM remonte et donc pour prouver que ça pourrait venir d’un plugin … mais rien, ça reste bas et ça continue de déscendre …
