Oui, tu as raison, C’est le daemon PHP qu’il faut trouver :
19Mio dans mon cas
Voilà la mienne:
jerry@jeedom:~ $ ps -eo size,pid,user,command --sort -size
SIZE PID USER COMMAND
711780 661 mysql /usr/sbin/mysqld
239188 2843 www-data php /var/www/html/plugins/jMQTT/resources/jmqttd/jmqttd.php --plugin jMQTT --socketport 1026 --pid /tmp/jeedom/jMQTT/jmqttd.php.pid
DE mon coté je confirme une perte de mémoire
la valeur est celle du demon jmqttd
un petit extrait sur quelques minutes
A 724 8 broker En Ligne , memoire 62208
[07:25]
A 725 1 broker En Ligne , memoire 64256
[07:26]
A 726 2 broker En Ligne , memoire 64256
[07:27]
A 727 2 broker En Ligne , memoire 66304
[07:28]
A 728 2 broker En Ligne , memoire 66580
[07:29]
A 729 1 broker En Ligne , memoire 68628
[07:30]
A 730 2 broker En Ligne , memoire 68628
[07:31]
A 731 2 broker En Ligne , memoire 68628
[07:32]
A 732 1 broker En Ligne , memoire 70676
[07:33]
A 733 2 broker En Ligne , memoire 70676
[07:34]
A 734 2 broker En Ligne , memoire 72724
[07:35]
A 735 2 broker En Ligne , memoire 72724
[07:36]
A 736 1 broker En Ligne , memoire 72448
[07:37]
A 737 2 broker En Ligne , memoire 74496
[07:38]
A 738 1 broker En Ligne , memoire 74636
[07:39]
A 739 1 broker En Ligne , memoire 76684
[07:40]
A 740 2 broker En Ligne , memoire 76684
[07:41]
A 741 2 broker En Ligne , memoire 78732
[07:42]
A 742 2 broker En Ligne , memoire 78732
[07:43]
A 743 2 broker En Ligne , memoire 78732
[07:44]
A 744 2 broker En Ligne , memoire 80780
[07:45]
A 745 2 broker En Ligne , memoire 80780
On a pu constater ces derniers jours que sur un Jeedom vierge avec JMQTT (beta), la reception d’un très grand nombre de messages MQTT (1000/min) ne provoquait pas de fuite de mémoire.
Je pense que c’est le déclenchement des scénarios/virtual/influxdb qui génère une fuite mémoire… ce n’est qu’une supposition tant que l’on aura pas réussi à reproduire le problème.
Hello,
Pour info j’ai un problème similaire également depuis plusieurs semaines.
Je suis sur la bêta et je fais les mise à jour a chaque fois qu’elles se présentent, donc toujours la dernière version.
Je constate une augmentation lente mais continue de la consommation de RAM jusqu’au point où après quelques jours la majorité de mes scénarios ne peuvent plus s’exécuter car la limite de mémoire PHP semble atteinte.
Une rapide analyse avec un « top » au moment où la RAM libre est au plus bas m’a montré que le process consommateur de RAM était un process PHP lancé par jmqtt, donc son daemon à mon avis.
En relançant le daemon jmqtt la RAM se libère instantanément et je suis a nouveau tranquille quelques jours avant de retomber dans les limites.
J’ai vraiment pas encore analysé ni fouillé plus loin pour le moment, tout ce que je sais pour l’instant c’est que c’est clairement en liaison avec jmqtt.
Mais est-ce un effet de bord ou un soucis interne au plugin je n’en sais encore rien.
Edit :
Dans mon cas la mémoire utilisée par le process :
php /var/www/html/plugins/jMQTT/resources/jmqttd/jmqttd.php --plugin jMQTT --socketport ...
augment de ± 30MB/h, et ne diminue jamais jusqu’à ce que je relance le daemon.
J’ai fais un script sh qui me log tout changement de la mémoire utilisée par ce process via la commande ‹ ps › et elle augmente de façon régulière 2MB par 2MB toutes les 4 à 6 minutes.
Je n’ai pas encore trouvé une corrélation avec un évènement extérieur au plugin.
1 « J'aime »
Pour info,
Je viens de repasser le plug’in en stable et j’ai absolument le même comportement, la charge mémoire gonfle de 36MB/H. C’est donc peut-être même pire.
Je vais donc le repasser en beta.
J’ai mis en place un scenario qui relance le daemon toutes les nuits à 2H30 pour le moment, et ce matin déjà 12% de mes 4Go de ram sont occupés par ce process, après un restart du daemon ça retombe à 1%.
Info supplémentaire, je tourne pas avec le broker en local, il est déporté dans une autre VM mais à mon avis ça doit pas changer grand chose.
Salut de mon coté le pansement est de relancer le demon toutes les 2 heures 
Je log toutes les minutes la taille.
0983|[2022-03-09 09:24:02]INFO : JMQTT:online 54752
0984|[2022-03-09 09:25:02]INFO : JMQTT:online 54752
0985|[2022-03-09 09:26:02]INFO : JMQTT:online 54752
0986|[2022-03-09 09:27:02]INFO : JMQTT:online 54752
0987|[2022-03-09 09:28:02]INFO : JMQTT:online 56800
0988|[2022-03-09 09:29:02]INFO : JMQTT:online 56800
0989|[2022-03-09 09:30:03]INFO : JMQTT:online 56800
0990|[2022-03-09 09:31:02]INFO : JMQTT:online 56800
0991|[2022-03-09 09:32:02]INFO : JMQTT:online 56800
0992|[2022-03-09 09:33:02]INFO : JMQTT:online 58848
0993|[2022-03-09 09:34:01]INFO : JMQTT:online 58848
0994|[2022-03-09 09:35:03]INFO : JMQTT:online 58848
0995|[2022-03-09 09:36:02]INFO : JMQTT:online 58848
0996|[2022-03-09 09:37:02]INFO : JMQTT:online 58848
0997|[2022-03-09 09:38:02]INFO : JMQTT:online 60896
0998|[2022-03-09 09:39:02]INFO : JMQTT:online 60896
0999|[2022-03-09 09:40:02]INFO : JMQTT:online 60896
0939|[2022-03-09 08:45:03]INFO : JMQTT:online 69184
0940|[2022-03-09 08:45:06]INFO : JMQTT:offline 69184
0941|[2022-03-09 08:45:10]INFO : re-démarrage du plugin jMQTT
0942|[2022-03-09 08:45:10]INFO : JMQTT:online ,
0943|[2022-03-09 08:45:11]INFO : JMQTT:offline ,
0944|[2022-03-09 08:45:12]INFO : JMQTT:online ,
0945|[2022-03-09 08:46:02]INFO : JMQTT:online 16500
0946|[2022-03-09 08:47:02]INFO : JMQTT:online 23136
1 « J'aime »
Bonjour,
le problème est présent uniquement avec la beta ?
Bonne journée
non, pas chez moi en tous cas :
Hello @meute,
Peux-tu nous dire si tu as activé la publication vers Influxdb sur des commandes jMQTT ?
De toute façon le problème vient du daemon php, nous travaillons à l’éradication de ce daemon au profit du daemon python, car php n’est pas fait (by design) pour tourner longtemps.
Je parlerais plus d’une couche que d’un pensement pour gérer les fuites 
Mais oui, c’est la façon la plus simple qu’on ait à date de palier au problème.
Plus d’infos prochainement.
Bad
1 « J'aime »
Hello,
Non, je n’utilise pas Influxdb.
Et j’ai vérifié quelques commandes au hasard et la publication vers influxdb y était désactivée.
Maintenant ça ne veut pas dire qu’il n’y ai pas une commande qui traine où ça aurait été activé à l’insu de mon plein gré … mais ça serait fastidieux d’aller passer en revue toutes les commandes pour vérifier, j’en aurais pour au moins 2 heures …
A moins que tu ais une commande SQL ou autre qui me permette de toutes les vérifier d’un coup à me proposer ?
Pas de requête SQL mon, mais le code suivant à mettre dans un bloc code d’un scenario :
foreach(jMQTTCmd::searchConfiguration('"influx::enable":"1"') as $cmd)
$scenario->setLog('cmd: '.$cmd->getHumanName());
Dans les logs du scenario tu auras les commandes pour lesquelles influx est actif (ou rien).
2 « J'aime »
Je n’en ai aucune où la publication vers influxdb est activée.
Merci pour ton retour, on te tiendra au courant quand on aura passé en beta des changements qui pourraient améliorer la situation.
1 « J'aime »
je suis sur la beta du 2022-03-02 01:01:20 et j’ai aussi une petite fuite de mémoire quelques mega /jours
ma config un Pi4 8G rasbian 10 en 32Bit
mon brocker est sur un orange pi a coté
j’ai que un seul équipement MQTT mais qui envoi au moins une info /min
Bonjour @Bad ,
Je me permets de revenir sur ce sujet.
J’ai migré pas mal d’échanges de mon système via MQTT.
J’avais constaté que mon niveau de RAM etait en augmentation constante sur mon RPi 4B 8Go et je suis ce post en attendant du nouveau.
Y aurait-il du nouveau dans la résolution de ce problème ?
Bonjour @Eridani78,
A date, il n’y a rien de nouveau, non.
Nous manquons de temps en ce moment pour faire l’« évolution magique qui va tout arranger »…
Le problème est intimement lié au daemon PHP, il faut changer beaucoup de choses pour s’en passer.
Si d’autres personnes ont ce problème, restez sur ce fil, on vous tiendra au courant.
Bad
1 « J'aime »
Merci pour l’update.
A l’occasion, si je peux aider pour du test/debbugage, je le ferais volontiers.
Malgré tout il fut une époque où ce daemon ne posait aucun problème, en tous cas chez moi, j’ai tourné probablement 3 ans avec JMQTT avec pas mal de topics souscrits et écrit pour la gestion de ma chaudière Vaillant avec Ebusd et ma RAM était parfaitement stable, c’était même le plugin le plus stable de mon installation dans lequel je n’avais jamais remis les mains pendant 3 ans.
Le problème a commencé chez moi autour de décembre 2021 mais quasi en même temps j’ai updaté le core en 4.2, basculé mon zwave et mon zigbee sous MQTT et déporté mosquito sur une autre machine … donc difficile à dire si c’est lors d’un update du plugin que c’est apparu ou si c’est à cause des l’évolutions de mon installation
Il est peut-être plus simple de se pencher sur le daemon dans un premier temps avant de chercher à tout prix à le migrer, si ça tombe c’est vraiment une toute petite connerie.
Malheureusement, cette fuite existait avant notre reprise du plugin :
Et en faisant des debugs relativement semblable à ceux-ci :
On s’est rendu compte que c’est json_decode() qui bouffe la mémoire. La seule solution pour éviter qu’une fonction du langage PHP ne vampirise la mémoire, c’est de ne pas la lancer dans un daemon. D’où la nécessité du retrait du daemon PHP.
Il y a peu, j’avais une version fonctionnelle et presque finie, mais on a décidé partir sur des mécanismes plus normalisé et facile à maintenir dans le temps pour la communication avec Jeedom.
Encore un peu de patience, on ne va pas vous laisser dans la panade ! De toute façon, c’est nécessaire pour aller vers la prochaine grosse fonctionnalité (qu’on a entamé avec le jsonPath).
Bad
4 « J'aime »