Consommation RAM en constante augmentation

Bonjour à vous,

J’ai un problème de performance avec Jeedom depuis peu et je ne parviens pas à en trouver la cause.
La consommation de RAM augmente jusqu’à plantage de Jeedom, je ne sais pas quoi faire pour identifier ce qui cause cet effet.
J’ai déjà arrêté pas mal de scénarios mais ça continue d’augmenter, voyez ici:

Un scénario ou un plugin ‹ inactif › ne consomme pas de RAM correcte?
Existe-t-il des commandes linux (je ne suis pas doué en linux) permettant de trouver les process qui consomme cette RAM? Et donc d’identifier quel scénarios ou plugin est en cause?

Je suis sur une box Atlas en 4.1.28.

Merci pour votre aide.

Sébastien

Ca peut etre normal ou anormal. il faudrait que tu colles ta page santé.

L’augmentation de la consommation de RAM n’ets pas en soi un pb, ca dépend avant tout de la valeur swapiness qui déchargera automatiquement la RAM en mémoire avec plus ou moins d’agressivité.
c’est sa saturation qui pose pb → plus suffisamment de RAM et donc utilisation du SWAP; moins performant

Non → ton scenario doit être géré par des process Jeedom, donc tout ce qui est en mémoire correspond aux process jeedom. donc ce qui est utilisé par Jeedom restera en mémoire
→ dit autrement, ce n’est as parceque tu ne lances plus ton scenario que tu va retrouver de la mémoire

Idem pour les plugin, tout dépend du plugin, certain qui ont leurs propres process peuvent libérer de la mémoire lorsque tu arrêtes le process, d’autres non.

ne pas oublier non plus que Linux a la fâcheuse tendance à conserver un maximum de choses en memoire et tant qu’il n’a pas besoin de mémoire supplémentaire, il ne la libèrera pas (cf valeur swapiness).

Maintenant qu’on a dit ca, ca ne veux pas dire qu’il n’y a pas de pb, et vu tes courbes, ca sent quand meme la fuite mémoire quelque part.
cf par exemple : Fuite mémoire sur béta

pour en avoir le cœur net …tu inactives des plugins et tu relances Jeedom et tu regardes si tu constates toujours cette augmentation de mémoire pour isoler le plugin qui poserai pb (en commençant par ceux qui ont des démons , cf moteur de taches > demons)

pour ce qui est d’une commande pour voir l’usage de la mémoire, tu peux essayer ceci :

ps -o pid,user,%mem,command ax | sort -b -k3 -r

Les process seront classés par ordre d’usage de la mémoire (%MEM), mais tu devrais surtout retrouver des process jeedom type mysqld, apache, python ou node.js.
Et si fuite mémoire, je pense que tu ne le verras pas
Pas sur que ca t’apporte de l’aide, mais on ne sait jamais

1 « J'aime »

Merci pour ta réponse.
J’ai déjà désactivé pas mal de scénarios et redémarré Jeedom juste après mais la RAM continue de descendre comme tu le vois dans le graphique.
Je vais continuer comme tu le propose: identifier les plugins ayant des démons, les arrêter les un après les autres en redémarrant Jeedom entre chaque plugin arrêté.
C’est pas cool cette instabilité, je dois pouvoir compter sur ma domotique.

Merci!

Sébastien

Tu as constaté des pbs ? des instabilités ? des ralentissements ?
Encore une fois, le fait que la RAM utilisée augmente ne veux pas dire que tu as des pbs.

Copies/Colles aussi ta page santé aussi.

EDIT : j’ai relu ton premier post :wink: ui repond donc à ma question !

Bonjour,

Tous les outils nécessaires sont présents dans les outils « administration système »: config jeedom > onglet os/sb, bouton « administration système » =>
image

Salut,

Voici ce que ça donne (j’ai redémarré hier soir):

 SIZE   PID USER     COMMAND
1888820 1860 mysql   /usr/sbin/mysqld
204008 3147 www-data /usr/bin/python3 /var/www/html/plugins/zigbee/resources/zigbeed/zigbeed.py --device /dev/ttyS2 --loglevel error --socketport 8089 --callback http://127.0.0.1:80/plugins/zigbee/core/php/jeeZigbee.php --apikey KLlbJb3WLHyixODbSauxvNNZnURk0Tut --cycle 0.3 --pid /tmp/jeedom/zigbee/deamon_1.pid --data_folder /var/www/html/plugins/zigbee/data/1 --device_folder /var/www/html/plugins/zigbee/data/device --controller ezsp --sub_controller elelabs --channel 15 --folder_OTA /var/www/html/plugins/zigbee/data/ota
145596 3042 www-data /usr/bin/python /var/www/html/plugins/openzwave/core/class/../../resources/openzwaved/openzwaved.py --device /dev/ttyACM0 --loglevel error --port 8083 --config_folder /var/www/html/plugins/openzwave/core/class/../../resources/openzwaved/config --data_folder /var/www/html/plugins/openzwave/core/class/../../data --callback http://127.0.0.1:80/plugins/openzwave/core/php/jeeZwave.php --apikey CV4XZwZnLK3y2ERO7CV4PwlY3lvJPmq5 --suppressRefresh 0 --cycle 0.3 --pid /tmp/jeedom/openzwave/deamon.pid
138848 2537 www-data /usr/bin/python3 /var/www/html/plugins/googlecast/resources/googlecast.py --loglevel none --socketport 55012 --sockethost 127.0.0.1 --callback http://127.0.0.1:80/plugins/googlecast/core/php/googlecast.api.php --apikey 8TlriwaFFGZWOj9rnx691NC7ZHA9KrsD --ttsweb https://spangenberger.eu.jeedom.link --ttslang fr-FR --ttsengine gtts --ttsspeed 1.2 --ttscache 1 --ttsgapikey AIzaSyD41z2aCepfjsehRow1_khVqv_nOqHcAE0 --gcttsvoice fr-FR-Wavenet-C --ttsdefaultrestoretime 1300 --ttsdefaultsilenceduration 300 --daemonname local --cyclefactor 1 --defaultstatus  
132000 2562 www-data php /var/www/html/plugins/jMQTT/resources/jmqttd/jmqttd.php --plugin jMQTT --socketport 1026 --pid /tmp/jeedom/jMQTT/jmqttd.php.pid
87560  2955 www-data /usr/bin/python3 /var/www/html/plugins/xiaomihome/resources/xiaomihomed/xiaomihomed.py --loglevel error --socketport 55019 --callback http://127.0.0.1:80/plugins/xiaomihome/core/php/jeeXiaomiHome.php --apikey mrgINSpN8ldnDiBKqfSqIgNOkc4nSkJt --cycle 0.05 --pid /tmp/jeedom/xiaomihome/deamon.pid
70380  2458 www-data nodejs /var/www/html/plugins/espeasy/resources/espeasy.js 192.168.1.15 http://127.0.0.1:80/plugins/espeasy/core/api/jeeEspeasy.php?apikey=jEVsX1A6Y4JwJR1gPBUhDI67IL38GQQ2 400
56444  2560 www-data python3 /var/www/html/plugins/jMQTT/resources/jmqttd/jmqttd.py --plugin jMQTT --loglevel error --socketport 1025 --apikey MtF8N3954VNLOD6ScHTLvx1h6UXcmthb --pid /tmp/jeedom/jMQTT/jmqttd.py.pid
55384  2865 www-data /usr/bin/python /var/www/html/plugins/teleinfo/ressources/teleinfo.py --type conso --port /dev/ttyUSB0 --vitesse 1200 --apikey QE4dvL8M8eUAYeLf3EdDxb2vDAgT2Qan --mode historique --socketport 55062 --cycle 0.3 --callback http://127.0.0.1:80/plugins/teleinfo/core/php/jeeTeleinfo.php --loglevel debug --cyclesommeil 0.5
52732  1557 root     /usr/sbin/NetworkManager --no-daemon
46584  1750 root     /usr/bin/python3 /usr/bin/fail2ban-server -xf start
44596  2395 root     /usr/bin/python3 /var/www/html/plugins/broadlink/resources/broadlinkd/broadlinkd.py --loglevel error --socketport 55013 --sockethost 127.0.0.1 --callback http://127.0.0.1:80/plugins/broadlink/core/php/jeeBroadlink.php --apikey hLdy4Bpnvpy9799UMyZ4bpDiedivKSIs --cycle 0.3 --pid /tmp/jeedom/broadlink/deamon.pid
25840  1861 root     /usr/lib/policykit-1/polkitd --no-debug
25044  1576 root     /usr/sbin/rngd -r /dev/urandom
23708  2843 www-data php /var/www/html/core/class/../php/jeeCron.php cron_id=226295
19804   682 root     /lib/systemd/systemd-journald
18632     1 root     /sbin/init
18496  1573 root     /usr/sbin/rsyslogd -n -iNONE
18184 29225 www-data /usr/sbin/apache2 -k start
16832  1745 root     /usr/bin/python3 /usr/share/unattended-upgrades/unattended-upgrade-shutdown --wait-for-signal
 9748 20874 www-data /usr/sbin/apache2 -k start

Pas cool, c’est SQL … comment trouvé ce qui génère çà?

Sébastien

Ce n’est pas une consommation si excessive que ca, donc jusque là rien ne montre un problème

Oui pour l’instant car comme je l’ai dit, j’ai redémarré Jeedom hier soir et la RAM est revenu à 78% puis doucement diminue de plus en plus à chaque instant.
Je refais le même test dans 2 jours et on verra si c’est toujours SQL qui augmente sa consommation.

Sébastien

as-tu aussi regardé coté charge CPU ?

Oui ça m’a l’air ok:
image

J’ai effectivement des pics CPU, je penses que ça arrive quand des scenarios ‹ lourds › font des calculs de statistiques mais ça me semble ok à ce niveau.
La charge CPU pourrait expliquer une augmentation de RAM ??? (le je ne comprends pas …)

Sébastien

Non, mais des ralentissements, oui !

Colle nous ta page santé STP

Je pense qu’il faut que tu suives le post dejà indiqué plus haut : Fuite mémoire sur béta

Tu peux déjà arrêter le plugin jmqtt et voir si ton pb est sur celui là.

Norbert

Avant que je fasse ça, j’ai observé une augmentation de la RAM (suite à la recommendation de @Mips ) sur le process mysql à 3:30 exactement !

 SIZE   PID USER     COMMAND
1983092 1860 mysql   /usr/sbin/mysqld
204008 3147 www-data /usr/bin/python3 /var/www/html/plugins/zigbee/resources/zigbeed/zigbeed.py --device /dev/ttyS2 --loglevel error --socketport 8089 --callback http://127.0.0.1:80/plugins/zigbee/core/php/jeeZigbee.php --apikey KLlbJb3WLHyixODbSauxvNNZnURk0Tut --cycle 0.3 --pid /tmp/jeedom/zigbee/deamon_1.pid --data_folder /var/www/html/plugins/zigbee/data/1 --device_folder /var/www/html/plugins/zigbee/data/device --controller ezsp --sub_controller elelabs --channel 15 --folder_OTA /var/www/html/plugins/zigbee/data/ota
145596 3042 www-data /usr/bin/python /var/www/html/plugins/openzwave/core/class/../../resources/openzwaved/openzwaved.py --device /dev/ttyACM0 --loglevel error --port 8083 --config_folder /var/www/html/plugins/openzwave/core/class/../../resources/openzwaved/config --data_folder /var/www/html/plugins/openzwave/core/class/../../data --callback http://127.0.0.1:80/plugins/openzwave/core/php/jeeZwave.php --apikey CV4XZwZnLK3y2ERO7CV4PwlY3lvJPmq5 --suppressRefresh 0 --cycle 0.3 --pid /tmp/jeedom/openzwave/deamon.pid
142240 2562 www-data php /var/www/html/plugins/jMQTT/resources/jmqttd/jmqttd.php --plugin jMQTT --socketport 1026 --pid /tmp/jeedom/jMQTT/jmqttd.php.pid
138848 2537 www-data /usr/bin/python3 /var/www/html/plugins/googlecast/resources/googlecast.py --loglevel none --socketport 55012 --sockethost 127.0.0.1 --callback http://127.0.0.1:80/plugins/googlecast/core/php/googlecast.api.php --apikey 8TlriwaFFGZWOj9rnx691NC7ZHA9KrsD --ttsweb https://spangenberger.eu.jeedom.link --ttslang fr-FR --ttsengine gtts --ttsspeed 1.2 --ttscache 1 --ttsgapikey AIzaSyD41z2aCepfjsehRow1_khVqv_nOqHcAE0 --gcttsvoice fr-FR-Wavenet-C --ttsdefaultrestoretime 1300 --ttsdefaultsilenceduration 300 --daemonname local --cyclefactor 1 --defaultstatus  

Aussi d’après vos suggestions, je m’interresse alors aux CRONs :
→ rien entre les minutes, ni 5 minutes, ni 10 minutes, ni 15 minutes … la RAM reste au même niveau d’utilisation.
→ ça ne peut donc venir que de quelque chose qui utilise le CRON30, vrai?

Et JMQTT utilise CRON (1 minute) et HEALTH (c’est quoi la fréquence?) donc surement pas ce plugin.

Je vais me pencher la dessus et désactiver les plugins et scénarios utilisant CRON30.

Est-ce la bonne approche?

Je reviens dans 15 minutes (30 minutes après le dernier test montrant l’augementation de la RAM) pour confimer cette hypotèse.

Merci!

Sébastien

J’arrêterai JMQTT et je regarderai ce qu’il se passe

1 « J'aime »

OK …
Mon hypotèse semble fausse, pas d’augmentation significative à 4:00

 SIZE   PID USER     COMMAND
1983584 1860 mysql   /usr/sbin/mysqld
204008 3147 www-data /usr/bin/python3 /var/www/html/plugins/zigbee/resources/zigbeed/zigbeed.py --device /dev/ttyS2 --loglevel error --socketport 8089 --callback http://127.0.0.1:80/plugins/zigbee/core/php/jeeZigbee.php --apikey KLlbJb3WLHyixODbSauxvNNZnURk0Tut --cycle 0.3 --pid /tmp/jeedom/zigbee/deamon_1.pid --data_folder /var/www/html/plugins/zigbee/data/1 --device_folder /var/www/html/plugins/zigbee/data/device --controller ezsp --sub_controller elelabs --channel 15 --folder_OTA /var/www/html/plugins/zigbee/data/ota
149408 2562 www-data php /var/www/html/plugins/jMQTT/resources/jmqttd/jmqttd.php --plugin jMQTT --socketport 1026 --pid /tmp/jeedom/jMQTT/jmqttd.php.pid
145596 3042 www-data /usr/bin/python /var/www/html/plugins/openzwave/core/class/../../resources/openzwaved/openzwaved.py --device /dev/ttyACM0 --loglevel error --port 8083 --config_folder /var/www/html/plugins/openzwave/core/class/../../resources/openzwaved/config --data_folder /var/www/html/plugins/openzwave/core/class/../../data --callback http://127.0.0.1:80/plugins/openzwave/core/php/jeeZwave.php --apikey CV4XZwZnLK3y2ERO7CV4PwlY3lvJPmq5 --suppressRefresh 0 --cycle 0.3 --pid /tmp/jeedom/openzwave/deamon.pid
143032 2537 www-data /usr/bin/python3 /var/www/html/plugins/googlecast/resources/googlecast.py --loglevel none --socketport 55012 --sockethost 127.0.0.1 --callback http://127.0.0.1:80/plugins/googlecast/core/php/googlecast.api.php --apikey 8TlriwaFFGZWOj9rnx691NC7ZHA9KrsD --ttsweb https://spangenberger.eu.jeedom.link --ttslang fr-FR --ttsengine gtts --ttsspeed 1.2 --ttscache 1 --ttsgapikey AIzaSyD41z2aCepfjsehRow1_khVqv_nOqHcAE0 --gcttsvoice fr-FR-Wavenet-C --ttsdefaultrestoretime 1300 --ttsdefaultsilenceduration 300 --daemonname local --cyclefactor 1 --defaultstatus  
87560  2955 www-data /usr/bin/python3 /var/www/html/plugins/xiaomihome/resources/xiaomihomed/xiaomihomed.py --loglevel error --socketport 55019 --callback http://127.0.0.1:80/plugins/xiaomihome/core/php/jeeXiaomiHome.php --apikey mrgINSpN8ldnDiBKqfSqIgNOkc4nSkJt --cycle 0.05 --pid /tmp/jeedom/xiaomihome/deamon.pid
70380  2458 www-data nodejs /var/www/html/plugins/espeasy/resources/espeasy.js 192.168.1.15 http://127.0.0.1:80/plugins/espeasy/core/api/jeeEspeasy.php?apikey=jEVsX1A6Y4JwJR1gPBUhDI67IL38GQQ2 400
56444  2560 www-data python3 /var/www/html/plugins/jMQTT/resources/jmqttd/jmqttd.py --plugin jMQTT --loglevel error --socketport 1025 --apikey MtF8N3954VNLOD6ScHTLvx1h6UXcmthb --pid /tmp/jeedom/jMQTT/jmqttd.py.pid
55384  2865 www-data /usr/bin/python /var/www/html/plugins/teleinfo/ressources/teleinfo.py --type conso --port /dev/ttyUSB0 --vitesse 1200 --apikey QE4dvL8M8eUAYeLf3EdDxb2vDAgT2Qan --mode historique --socketport 55062 --cycle 0.3 --callback http://127.0.0.1:80/plugins/teleinfo/core/php/jeeTeleinfo.php --loglevel debug --cyclesommeil 0.5
52744  1557 root     /usr/sbin/NetworkManager --no-daemon
46584  1750 root     /usr/bin/python3 /usr/bin/fail2ban-server -xf start
44596  2395 root     /usr/bin/python3 /var/www/html/plugins/broadlink/resources/broadlinkd/broadlinkd.py --loglevel error --socketport 55013 --sockethost 127.0.0.1 --callback http://127.0.0.1:80/plugins/broadlink/core/php/jeeBroadlink.php --apikey hLdy4Bpnvpy9799UMyZ4bpDiedivKSIs --cycle 0.3 --pid /tmp/jeedom/broadlink/deamon.pid
25840  1861 root     /usr/lib/policykit-1/polkitd --no-debug
25044  1576 root     /usr/sbin/rngd -r /dev/urandom
23708  2843 www-data php /var/www/html/core/class/../php/jeeCron.php cron_id=226295
19804   682 root     /lib/systemd/systemd-journald

ça m’embête d’arrêter JMQTT car je l’utilise pour communiquer des informations entre 2 Jeedom.
MAIS : il est vrai que j’observe ce problème depuis l’installation de JMQTT sur ce Jeedom … par contre je n’ai pas ce problème sur mon second Jeedom! Pourquoi ?

Sébastien

Je pense que tu as raison @ngrataloup , depuis que j’ai arrete JMQTT la RAM se stabilise…
Pas de recuperation mais ca ne descend plus depuis plus d’une heure.

Hum …

Sebastien

Bonsoir.

Je suis fortement étonné de voir autant de données, 2 fois 5 Go, en upload et download comptabilisées en seulement 18h de uptime.
Sauf si vous avez une explication sur ce point.

En 33 jours j’ai 4 Go et 3 Go.

Capture d’écran du 2022-03-17 21-39-22
Capture d’écran du 2022-03-17 21-39-42

Oups, je suis petit joueur alors !
Je trouve cela énorme.

1 « J'aime »