Identifier la cause des pic de charges

Bonjour,

J’ai installé hier le plugin monitoring pour avoir des infos sur l’utilisation du CPU et de la charge de mon RPI 3. Je constate qu’il chauffe beaucoup (à mon gout) et que la charge est dans le rouge (j’ai recopié les valeur de la doc, j’avoue ne pas trop comprendre cette valeur)
image
image

dans les logs (fichier /var/log/syslog) j’ai toutes les 5 minutes :

Jan 28 07:10:01 dom CRON[17970]: (root) CMD (/usr/bin/php /var/www/html/core/php/watchdog.php >> /dev/null)
Jan 28 07:10:01 dom CRON[17971]: (www-data) CMD (/usr/bin/php /var/www/html/core/php/jeeCron.php >> /dev/null)

Concernant la ligne jeeCron, elle se répète beaucoup plus, je suppose que c’est lié aux divers scénarios.
En revanche je ne sais pas a quoi correspond watchdog, je n’ai pas de plugin ayant ce nom (j’ai vu qu’il y en avait un dans le market…)

Je constate que la ligne ci-dessous est revenu (moins régulièrement qu’avant), c’est le bluetooth interne utilisé par le blea…

Jan 28 08:40:46 dom kernel: [ 2005.369078] Bluetooth: hci1: Frame reassembly failed (-84)

J’essaye de voir ce qu’il est possible de faire sans changer de matériel pour le moment.

A l’époque en 2016, j’avais installé dans ce boitier, il faut peut-être que j’investisse dans un meilleur dissipateur thermique que ceux livré avec le boitier…
image

Bonjour
Suite à mes pb de perfs aussi je fais tourner ce script toutes les 5 minutes grâce au plugin script:

#!/bin/bash

texte="$(ps -eo pmem,pcpu,pid,args | tail -n +2 | sort -rnk 1 | head)"

datetime=`date '+%d/%m/%Y %H:%M:%S'`

echo " " >> "/var/www/html/log/-My_Chercheperfs"
echo "====================================================================================================================" >> "/var/www/html/log/-My_Chercheperfs"
echo $datetime >> "/var/www/html/log/-My_Chercheperfs"
echo " " >> "/var/www/html/log/-My_Chercheperfs"
echo "$texte" >> "/var/www/html/log/-My_Chercheperfs"
echo " " >> "/var/www/html/log/-My_Chercheperfs

çà me log la liste les process gourmants toutes les 5 minutes pour voir les évolutions:

====================================================================================================================
28/01/2021 11:55:02
16.8  0.4   772 /usr/sbin/mysqld
4.8  0.0  1842 homebridge-config-ui-x
4.7  0.1  1673 homebridge
3.9  0.0 10344 node /var/www/html/plugins/pronotlink/resources/bin/server.js
2.7  0.4  2146 /usr/bin/python /var/www/html/plugins/openzwave/core/class/../../resources/openzwaved/openzwaved.py --device auto --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 DfwV1KJYblablablagjCxO6 --suppressRefresh 0 --cycle 0.3 --pid /tmp/jeedom/openzwave/deamon.pid
2.0 23.0 32562 php /var/www/html/core/class/../php/jeeCron.php cron_id=9
1.9 15.0 32587 php /var/www/html/core/class/../php/jeeCron.php cron_id=10
1.8 15.0 32577 php /var/www/html/core/class/../../core/php/jeeScenario.php scenario_id=139 trigger=schedule message='Scenario execute automatiquement sur programmation'
1.8 15.0 32481 /usr/bin/php /var/www/html/core/php/jeeCron.php
1.8 14.0 32583 php /var/www/html/core/class/../../core/php/jeeScenario.php scenario_id=184 trigger=schedule message='Scenario execute automatiquement sur programmation'
6 « J'aime »

Bonjour,

Merci pour ton script, je viens de l’implémanter dans mon jeedom, c’est top (attention tu as oublié de copier le dernier " à la fin du script)

sinon voici mes logs (toujours les mêmes) :

28/01/2021 13:09:09
10.6  3.6   626 /usr/sbin/mysqld
4.7  0.0  1491 nodejs /var/www/html/plugins/alexaapi/resources/alexaapi.js http://192.168.1.xxx amazon.fr alexa.amazon.fr xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 400
4.6  0.1  1788 nodejs /var/www/html/plugins/rflink/resources/rflink.js http://127.0.0.1:80/plugins/rflink/core/api/rflink.php?apikey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx /dev/ttyACM0 none error
4.4  3.1  2173 /usr/bin/python /var/www/html/plugins/openzwave/core/class/../../resources/openzwaved/openzwaved.py --device /dev/ttyACM1 --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 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx --suppressRefresh 0 --cycle 0.3 --pid /tmp/jeedom/openzwave/deamon.pid
3.7  0.6  1459 /usr/sbin/apache2 -k start
3.4  1.7  2023 php /var/www/html/core/class/../php/jeeCron.php cron_id=207782
3.3  0.4  1641 /usr/bin/python3 /var/www/html/plugins/googlecast/resources/googlecast.py --loglevel error --socketport 55012 --sockethost 127.0.0.1 --callback http://127.0.0.1:80/plugins/googlecast/core/php/googlecast.api.php --apikey xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx --ttsweb http://192.168.1.xxx --ttslang fr-FR --ttsengine gtts --ttsspeed 1.2 --ttscache 1 --ttsgapikey none --gcttsvoice fr-FR-Standard-A --ttsdefaultrestoretime 1300 --ttsdefaultsilenceduration 300 --daemonname local --cyclefactor 1 --defaultstatus  
3.2  0.6   660 /usr/sbin/apache2 -k start
3.1  0.6 29613 /usr/sbin/apache2 -k start
3.1  0.6  5584 /usr/sbin/apache2 -k start

Du coup je sais maintenant que les plus consommateurs sont : plugin-alexaapi, plugin-rflink, plugin-openzwave et plugin-googlecast

AlexaApi et GoogleCast sont utilisés uniquement pour un faire parler mes enceintes connectés
rflink et zwave c’est pour la remontés et commandes de prises, thermomètre, vannes, …

Dans les logs AlexaApi j’ai ces logs qui se repetent (je ne sais pas si ont peu faire quelque chose) :

// ...
[2021-1-28 12:30:11][] : Alexa-Remote: Authentication check successfull
[2021-1-28 12:32:08][] : {API}: Alexa.updateallalarms: Retour vide
[2021-1-28 12:45:10][] : Alexa-Remote: Authentication check successfull
[2021-1-28 12:48:07][] : {API}: Alexa.updateallalarms: Retour vide
[2021-1-28 13:00:14][] : Alexa-Remote: Authentication check successfull
[2021-1-28 13:00:18][] : {API}: Alexa.updateallalarms: Retour vide
[2021-1-28 13:15:10][ERROR] : Alexa-Remote ║ <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title>Website Temporarily Unavailable</title>
</head>
<body>
<p>&nbsp;</p>
<center><img src="http://g-ecx.images-amazon.com/images/G/01/website/errors/503/generic.png" alt="website temporarily unavailable" width="500" height="300"></center>
</body>
</html>
[2021-1-28 13:15:10][] : Alexa-Remote: Authentication check returned error: Error: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title>Website Temporarily Unavailable</title>
</head>
<body>
<p>&nbsp;</p>
<center><img src="http://g-ecx.images-amazon.com/images/G/01/website/errors/503/generic.png" alt="website temporarily unavailable" width="500" height="300"></center>
</body>
</html>
. Still try request

Dans la configuration du plugin-alexaapi, il y a le cron suivant, je suppose que l’authentificaiton à lieu tous les jours à 3h33, je vois juste cette trace

[2021-1-28 3:33:05][] : {API}: Restart
[2021-1-28 3:33:05][] : {API}: ******************************************************************
[2021-1-28 3:33:05][] : {API}: *****************************Relance forcée du Serveur*************
[2021-1-28 3:33:05][] : {API}: ******************************************************************
[2021-1-28 3:45:08][ERROR] : Alexa-Remote ║ <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title>Website Temporarily Unavailable</title>
</head>
<body>
<p>&nbsp;</p>
<center><img src="http://g-ecx.images-amazon.com/images/G/01/website/errors/503/generic.png" alt="website temporarily unavailable" width="500" height="300"></center>
</body>
</html>
[2021-1-28 3:45:08][] : Alexa-Remote: Authentication check returned error: Error: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title>Website Temporarily Unavailable</title>
</head>
<body>
<p>&nbsp;</p>
<center><img src="http://g-ecx.images-amazon.com/images/G/01/website/errors/503/generic.png" alt="website temporarily unavailable" width="500" height="300"></center>
</body>
</html>
. Still try request
[2021-1-28 3:48:07][] : Alexa-Remote: Authentication check successfull
[2021-1-28 3:48:08][] : {API}: Alexa.updateallalarms: Retour vide

@sigalou si tu as un peu de temps, peux-tu me dire si c’est grave stp ? et si je peux faire quelque chose.

Merci à tous pour votre aide

Hello,
Tu as fait un top en ssh ?

Merci,

Voici le résultat du top :
image

Essaye de désactiver tes plugins un par un pour voir si l’un d’eux en particulier te fait monter la charge.

J’ai désactivé alexaapi et la charge est descendu :
image

Cela confirme que le script de @loic.gouraud est top pour identifier ce qui consomme le plus :slight_smile:

Maintenant faut que je trouve pourquoi la plugin consomme autant.

La charge a diminué : image
Lorsque je reactive le plugin-alexaapi ça remonte : image

Bonjour,

Merci pour le script

je l’ai implémenté aussi car je trouve que depuis quelques mois j’ai une augmentation de la charge sur ma Smart (up to date).

Je viens de regarder :
image

Mon graphique est une moyenne par jour de la charge 1m
image

Onglet santé :

j’ai 49 équipement Zwave (19 sur piles) / une 10ene en BLEA / 32 scenario.
je n’ai pas l’impression d’avoir trop de chargé ma box.

Voici ce que me remonte les logs du script .

12.0  3.5   542 /usr/sbin/mysqld
 3.1  2.3  3841 /usr/bin/python /var/www/html/plugins/openzwave/core/class/../../resources/openzwaved/openzwaved.py --device /dev/ttyS1 --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 <XXX>--suppressRefresh 0 --cycle 0.3 --pid /tmp/jeedom/openzwave/deamon.pid
 2.4  0.0 22860 nodejs /var/www/html/plugins/maillistener/resources/maillistener.js <MAIL>@imap.gmail.com http://<IP>/plugins/maillistener/core/api/maillistener.php?apikey=<XXX><MAIL><PWD> imap.gmail.com 993 false /var/www/html/plugins/maillistener/resources/attachments/
 2.3  1.9  1463 /usr/sbin/apache2 -k start
 2.2  1.9 21195 /usr/sbin/apache2 -k start
 2.2  1.9 13613 /usr/sbin/apache2 -k start
 2.2  1.8 32450 /usr/sbin/apache2 -k start
 2.0 60.0  4480 php /var/www/html/core/class/../../core/php/jeeScenario.php scenario_id=34 trigger=schedule message='Scenario execute automatiquement sur programmation'
 2.0 57.0  4491 php /var/www/html/core/class/../../core/php/jeeScenario.php scenario_id=47 trigger=schedule message='Scenario execute automatiquement sur programmation'
 2.0 56.0  4483 php /var/www/html/core/class/../../core/php/jeeScenario.php scenario_id=38 trigger=schedule message='Scenario execute automatiquement sur programmation'

J’en déduis que c’est Zwave et maillistener qui consomment, est ce bien cela ?
Je n’ai pas modifié ces deux plugin depuis longtemps.

Pour Zwave je ne peux rien faire je pense. (c’est la base de ma domotique)
Et pour maillistener je n’ai qu’une adresse qui est écoutée et je ne reçois pas énormément de mail ( 2 ou 3 par jours ) donc je ne pense pas pouvoir jouer sur ce plugin non plus.
J’ai quelques gros scenarios ( alarme / présence ( gps nut …) / gestion impulsion Gaz…) mais ce n’est pas non plus énorme.

Puis je faire autre chose pour identifier les pic de charges ?

Merci d’avance,

Bonjour,

Cela vaudrait peut-être le coup d’identifier ce que font les 3 process jeeScenario.
Ce doit être des scénarios qui sont exécutés de façon asynchrone ou en parallèle)…

A+
Bernard

Bonjour,
Un des process est pour la présence de ma femme
L’autre pour ma présence
En plus de déclencheur (Nut/Wifi/Gps) ils sont programmé pour s’exécuter toutes les 5 min ( je viens de supprimer les deux programmation pour voir)

Le troisième pour le script sur le pic de charge.

Merci

Re,

Ce qui m’étonne c’est que ces process semblent être là en permanence.
Normalement, ils ne devraient plus être affichés dès que leur tâche est terminée.

A+

Tu peux peut-être montrer le contenu de chaque scénario ?

Si je tri par l’utilisation cpu en premier, je constate que je n’ai pas les mêmes plugins qui consomme beaucoup.

ps -eo pcpu,pmem,pid,args | tail -n +2 | sort -rnk 1 | head
*** MEM ***
29/01/2021 13:16:17
20.8  3.4   626 /usr/sbin/mysqld
4.5  0.0 10022 nodejs /var/www/html/plugins/alexaapi/resources/alexaapi.js http://192.168.1.22 amazon.fr alexa.amazon.fr xxx 400
3.9  3.1  2173 /usr/bin/python /var/www/html/plugins/openzwave/core/class/../../resources/openzwaved/openzwaved.py --device /dev/ttyACM1 --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 xxx --suppressRefresh 0 --cycle 0.3 --pid /tmp/jeedom/openzwave/deamon.pid
3.8  0.5 16152 /usr/sbin/apache2 -k start
3.7  0.6 30854 /usr/sbin/apache2 -k start
3.7  0.6 27531 /usr/sbin/apache2 -k start
3.5  1.7 24891 php /var/www/html/core/class/../php/jeeCron.php cron_id=207782
3.3  0.6 27489 /usr/sbin/apache2 -k start
3.2  0.3  1888 php /var/www/html/core/class/../php/jeeCron.php cron_id=204426
3.1  0.6 26968 /usr/sbin/apache2 -k start

*** CPU ***
5.6  0.0 21565 [kworker/2:1-events]
5.1  2.4  1527 /usr/bin/python3 /var/www/html/plugins/blea/resources/blead/blead.py --loglevel error --device hci1 --socketport 55008 --sockethost 127.0.0.1 --callback http://127.0.0.1:80/plugins/blea/core/php/jeeBlea.php --apikey xxx --daemonname local --noseeninterval 4 --scaninterval 29 --scanmode passive --pid /tmp/jeedom/blea/deamon.pid
4.8  0.0  4738 [kworker/2:0-events]
3.4 20.8   626 /usr/sbin/mysqld
3.4  1.8  2044 /usr/bin/python /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 xxx --cycle 0.05 --pid /tmp/jeedom/xiaomihome/deamon.pid
3.1  3.9  2173 /usr/bin/python /var/www/html/plugins/openzwave/core/class/../../resources/openzwaved/openzwaved.py --device /dev/ttyACM1 --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 xxx --suppressRefresh 0 --cycle 0.3 --pid /tmp/jeedom/openzwave/deamon.pid
1.7  3.5 24891 php /var/www/html/core/class/../php/jeeCron.php cron_id=207782
1.3  0.0 30791 [kworker/2:3-events]
0.7  2.7 32716 /usr/sbin/apache2 -k start
0.6  3.7 30854 /usr/sbin/apache2 -k start

Du coup je constate que le plugin-blea, plugin-xiaomihome et plugin-openzwave sont aussi consommateur et pour moi la température > 60 est fortement lié à ça…
Je vais essayé de désactivé BLEA pour voir ce que cela donne au niveau de la température.

Ils ne sont pas la en permanance

Execution de 13h20

12.0  3.5   542 /usr/sbin/mysqld
 3.1  2.3  3841 /usr/bin/python /var/www/html/plugins/openzwave/core/class/../../resources/openzwaved/openzwaved.py --device /dev/ttyS1 --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 hLZNE3UvLTeavWF9Mr94f64Yu79hfD3e --suppressRefresh 0 --cycle 0.3 --pid /tmp/jeedom/openzwave/deamon.pid
 2.4  0.0 22860 nodejs /var/www/html/plugins/maillistener/resources/maillistener.js communication.jeedom.home@imap.gmail.com http://192.168.0.51/plugins/maillistener/core/api/maillistener.php?apikey=tyH8v6v5bs5p7FIuBOXy4Igl2vcb8gxG communication.jeedom.home fhkihkgnspebbuie imap.gmail.com 993 false /var/www/html/plugins/maillistener/resources/attachments/
 2.0 71.0 11212 php /var/www/html/core/class/../php/jeeCron.php cron_id=9
 2.0 60.0 11226 php /var/www/html/core/class/../php/jeeCron.php cron_id=10
 2.0 57.0 11233 php /var/www/html/core/class/../../core/php/jeeScenario.php scenario_id=12 trigger=schedule message='Scenario execute automatiquement sur programmation'
 2.0  0.0 20738 php /var/www/html/core/class/../php/jeeCron.php cron_id=1278
 1.9 53.0 11246 php /var/www/html/core/class/../../core/php/jeeScenario.php scenario_id=47 trigger=schedule message='Scenario execute automatiquement sur programmation'
 1.9 47.0 11250 php /var/www/html/core/class/../php/jeeCron.php cron_id=13
 1.8 23.5 11131 /usr/bin/php /var/www/html/core/php/jeeCron.php

Mais les voici quand même :
image



Merci,

Re,

Pas évident de trop comprendre ce qui se passe.
Les commandes que tu utilises dans le scénario activent-ils des scripts?

Par exmple, pour la charge mysql est assez consommateur de ressources : 3.5, en comparaison le jeeScenario ou jeeCron sont à > à 60 ce qui apparaît beaucoup. A lisser dans le temps, mais bon cela peut expliquer les pics de charge, il ya plusieurs process comme cela.
Il faudrait voir ce qui a été changé sur ta configuration depuis le constat de pic de charge.

A+
Bernard

PS : le scénario n’est pas déclenché toutes les 5 minutes mais à la demande suivant certains événements qui peuvent se produire en rafale, peut-être.

Cela vaudrait le coup en entrée de script de logger le trigger du scénario.

Merci pour la reponse,

Concernant l’execution toutes les 5 minutes, j’ai retiré la programmation * /5 * * * * .
Quand il y a du mouvement dans le GPS oui, il est appelé souvent. ( car le téléphone fait un update de la position gps )

Concernant le script,

2.0 60.0 11226 php /var/www/html/core/class/../php/jeeCron.php cron_id=10

A quoi correspond le 2.0 et le 60.0 ?

Cron 9/10/13 correspondent à :

Y a t il autre chose a regarder ?

Merci

RE,

Le calcul du % cpu est très linuxien …
Cependant, il faut retenir que les valeurs retournées correspondent à une utilisation au cours de la période.
Donc, le process mysql qui est surement le plus utilisé avec apache et zwave présente un taux de 3.5.
Alors que les process qui sont activés ont une valeur de 23 pour un et pour les autres de > 50. Ce qui relativement apparaît assez énorme avec une charge 15 fois supérieure au process mysql.

Dans ton scenario, il faudrait logger le trigger qui a déclenché le scénario. Cela permettrait d’identifier quel déclencheur active le scénario et de mettre en évidence la fréquence d’activation.
Est-ce que tu peux détailler ce que fait le cron id = 10 ? C’est un script ? Un scénario ? Montrer le code ?

Par ailleurs, une idée simpliste serait dans un premier d’inactiver le scénario afin de vérifier que l’origine du pic de charge est bien là.

A+
Bernard

Hello @Heliospeed le serveur est temporairement en panne, peut etre qu’amazon fait des manip sur son serveur à 03h33 du matin. Tu peux désactiver la relance sur la config du plugin.
Depuis la derniere version stable, je déconseille cette relance du lien avec le serveur.

image

J’ai été étonné par ton TX/RX de ton Jeedom - 160Go en 4 jours !!!
Vu sur un autre post, si Mysql travaille beaucoup faudrait voir s’il n’y a pas un truc à faire sur la base
image

Bonsoir,

Intéressant

Comment identifier ce qui consomme des données ?

Merci, j’avais tout relancé (refais le coockie au cas ou) et depuis je n’ai plus les logs en erreur.
Après ce n’est pas le #plugin-alexaapi qui consommait beaucoup de CPU :slight_smile: