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.
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 ?
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
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 ?
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.
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).
Une rapide recherche sur un memory leak et json_decode() donne des résultat à foison donc ça semble effectivement être un problème très courant et récurent.
Et effectivement avec l’évolution de mon installation json_decode() à certainement plus de « boulot » qu’avant, bien que déjà rien qu’avec Ebusd pour ma chaudière je devais déjà parser assez « profondément » dans pas mal de topics en json pour en extraire les valeurs.
Pour le moment je relance le daemon 4 fois par 24H à heure fixes et ça tien comme ça.
