A chaque pic correspond à un reboot de l’OS (merci le watchdog du raspberry)
Pour « ralentir » la fréquence des crash, j’ai fais passer la swap de 1 à 2Go, et modifié le swapinness (de 60 à 10), mais cela ne fait que ralentir la fréquence des crashs
J’ai remarqué que c’était le démon jMQTT qui consommait, cela ressemble à une fuite mémoire:
Note: je n’ai pas réussi à redémarrer le démon par l’interface. Obligé de passé par une petite commande kill …
Erreur sur la fonction deamon_start du plugin : Le port du démon websocket (1026) est déjà utilisé par le pid 28573 : php /var/www/html/plugins/jMQTT/resources/jmqttd/jmqttd.php --plugin jMQTT --socketport 1026 --pid /tmp/jeedom/jMQTT/jmqttd.php.pid
La commande smem confirme l’utilisation de la swap (pid identique)
jeedom:~# smem
PID User Command Swap USS PSS RSS
(...)
28573 www-data php /var/www/html/plugins/j 397440 111348 112655 124920
(...)
Un point particulier m’interesse. On soupconne le daemon PHP WebSocket de provoquer cette fuite mémoire. Vous serait-il possible de relever la conso mémoire de ce process sur quelques jours : php /var/www/html/plugins/jMQTT/resources/jmqttd/jmqttd.php --plugin jMQTT --socketp...
De mon coté je viens d’activer l’historisation sur ma VM x86, mais je n’ai pas l’impression que ca monte.
J’ai vu 2-3 articles sur ce problème et cela viendrait du comportement du garbage collector qui ne se déclenche que bien bien plus tard. Donc j’ai ajouté un appel explicite à celui-ci toutes les 5 minutes.
C’est poussé en beta. A voir donc si ca résoud.
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.
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.
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.
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 ?
