Chasse à la charge CPU

Utilisation du core de Jeedom
1

Bonjour,

Je fais toujours la chasse à la conso CPU et la charge en général, mais pour l’instant j’ai pas trouvé de méthode efficace
Courant avril, grosse hausse alors que niveau fonctions, j’ai pas ajouté de gros trucs… Pourtant

  • J’ai viré les répétitions des valeurs partout, pas de grosse révolution
  • J’ai limité les historiques au plus juste/utile
  • J’ai tenté d’activer/désactiver les plugins pour essayer de trouver un coupable… mais pas grand chose.
  • J’optimise mes scénarios pour ne les déclencher que quand nécessaire

J’avais mis ça sur le compte du passage de buster-lite 32b à la version 64b non lite
Et puis pendant la semaine de vacances (donc pas à la maison tout le temps) magie, ça se divise par 5 :flushed: :

image
image1428×851 94.9 KB

Forcement, j’ai pas fait de lien entre mes quelques actions et le changement

J’ai viré BLEA un gros consommateur si on tient compte des infos remontées par top/htop mais c’est pas significatif (mais j’ai quand même besoin de zwave, broadlink,rfxcom qui sont aussi dans mon top3)

image
image1302×759 112 KB

Bref, je suis preneur d’idées et/ou methodes

2

Change de matériel = Solutions ultime perso je suis passer sur Odroid N2 et j’ai plus aucun probleme

3

Oui, mais c’est pas du tout l’objectif… Non seulement parce que ça fonctionne bien globalement mais surtout ça reviens à acheter une nouvelle voiture quand le niveau de carburant est bas dans l’actuelle…
Si changement de matos un jour, je passerai à un nuc…

4

dans ce cas rajoute un moteur, (jeelink).
mais perso 20 a 30% du cpu c’est vraiment rien

5

oui ça c’est une solution, j’ai plusieurs autre pi qui trainent/glandent… Par contre, on en reviens au même souci : identifier le consommateur pour l’isoler

6

Bas commencerais
par mettre les Gros consommateur d’un coté( Protocole zwave, BLEA, zigbee …)

7

investigations
si (pour zwave tu peux limité le retour de valeur) lux hum,temp,…
genre tranche 1° pour frigo. ou par tranche de 5 pour mon eau chaude.
pile et charge vont apprécié
une fois validé le comportement zwave met au max le réveil.

la repet,
le calcul (moyen,max,min) prefere aucun
c’est des traitements. mais depuis la gestion à été optimisé (mysql directe je crois)

regarde des virtuels : chaque cmd scénario dans un virtuel c’est un traitement au changement de l’état
donc si réel besoin ou passage api js (consultatif)
scénarios avec déclenchement et condition (si necessaire)
j’ai de memoiire désactivé le log événement jeedom
et fait des modif bios rasp config.txt/cmdline.txt (genre desactivation bt)

plug débarras

Screenshot_20200801-202253_Chrome
Screenshot_20200801-202253_Chrome1080×1920 368 KB

plug garage

Screenshot_20200801-202221_Chrome
Screenshot_20200801-202221_Chrome1080×1920 367 KB

tous n’y est pas (gmail,…)

j’ai prévu de me penché sur teleinfo

c’est débarras qui gère les scenarios

Screenshot_20200801-201612_Chrome
Screenshot_20200801-201612_Chrome1080×1920 374 KB

8

Merci @ajja17orangepour ces idées

  • Coté chauffage, remontée toutes les 15 minutes et en été pas de pilotage
  • Il me reste un oeil fibaro, qui effectivement bouffe les piles, pile HS depuis 2 semaines, j’ai pas remplacé mais je note pour ce périphérique.

Oui les calculs ont lieu la nuit. et j’ai effectivement limité les traitements

Là j’ai un peu de recherche/boulot, j’utilise pas mal les virtuels sans pour autant faire des doublons… J’aime pas les variables :innocent:
image

ça c’est fait. Pas de boucle (sauf une) etc…

idem aussi

Un poil plus que 1 sur 1 minute, c’est pas mal
Pour info et pour comparer quelle est la complexité de ta config ?
image
image

9

Screenshot_20200801-205753_Chrome
Screenshot_20200801-205753_Chrome1076×809 139 KB

Screenshot_20200801-205615_Chrome
Screenshot_20200801-205615_Chrome1078×698 130 KB

beaucoup ne pointe sur rien
des restes, comme des scénarios désactivé (memoire)

10

Coté chauffage, remontée toutes les 15 minutes et en été pas de pilotage

si changement ou permanent ?

11

Les 7 têtes Danfoss se réveillent toutes les 15 minutes et push leurs infos. Coté pilotage, pas d’envoi de consignes si pas de changement. Consignes récupérées au moment du refresh donc

12

image
image1440×900 169 KB

tu as regardé avec admirer ta bdd ?
car tu es 5 fois plus
car si ça fait longtemps et que tu modifies tes anciennes valeurs ne change pas, pire certaines valeur reste voir il y a des erreurs « valeur avec des chiffres bizarre », voir des id inexistant
du au restore (je crois)

c’est en jouant avec api js que j’ai vu que pour avoir un mini sur 2 ans que ça prenait du temps (trop genre 1 minute)

perso pour y aller avec douceur
création d’equipement (via jeedom)
pour y coller l’historique d’un equipement réel (via jeedom)
et ensuite je joue avec admirer

je déplace regroupe tous dans history

REPLACE INTO `history` (`cmd_id`,`datetime`,`value`)

SELECT DISTINCT `cmd_id`,
`datetime`,
`value`
FROM `historyArch` 
WHERE `cmd_id` = '523'

et aprés selon ton besoin
tu fais tranquilement tes recherches

image
image787×576 39.3 KB

voir via requête
exemple : recherche de doublon
image
image765×697 43.7 KB

SELECT   COUNT(`value` ) AS nbr_doublon, `value`,`datetime`
FROM   `historyArch` 
WHERE `cmd_id` = '4188' AND `datetime` >= '2017-01-01 00:00:01' AND `datetime` <= '2017-01-01 23:59:59'
GROUP BY `value`
HAVING   COUNT(`value`) > 1

ou tes optimisations
exemple

REPLACE INTO `historyArch` (`cmd_id`,`datetime`,`value`)

SELECT DISTINCT `cmd_id`,
concat( date(`datetime` ) , ' ', sec_to_time(time_to_sec(`datetime` )- time_to_sec(`datetime` )%(15*60))) as created_dt_new,
round(avg(`value`),1)
FROM `history` 
WHERE `cmd_id` = '4180'
group by created_dt_new

exemple de recherche combien tu as d’enregistrement un jour present/non présent et si la différence est importante sur quel id ?

enfin c’est surtout la variation présence/absence qui est importante

1 « J'aime »
13

Pas tout à fait, car c’est du cumulé sur 1h, mais avec moins de commandes je reste à un usage supérieur au tien

Bon j’ai un peu de boulot en perspective avec l’analyse de la base. Merci

14

Bon, au final j’ai purgé toute la base historyArch (j’ai la copie ailleurs)… réinstallé le pi et remis le dernier backup

image
image893×115 5.36 KB

ça n’explique tout clairement mais pour l’instant ça marche

15

Bon je viens de voir aussi un truc avec la version beta 2020-06-25 10:41:10 du plugin monitoring…
Les valeurs 1/5 et 15 de la charge ne sont présentes que toutes les 15 minutes… Donc je suis pas certain de la pertinence de 1 et 5

image
image1920×1080 323 KB

Idem chez toi ? Si oui, je créerai un sujet dédié pour le plugin

16

J’ai pas d’historique mais je vois que c’est un cron 15 mn
Actu a 19h45 et maintenant
C’est pour éviter de saturer ton cpu de requête (de mémoire une vieille demande) auparavant 5 min
C’est un indicateur

Après tu peux passer au script sh ou un scénario code « exec ssh »

Pour idée un scénario code boucle (dans en variable)
Si charge < 3 dans 5 minutes
Sinon dans 15 mn

Edit
Si tu veux te crée des cmd perso avec monitoring
https://forum.jeedom.com/viewtopic.php?t=1331&start=560#p95103

17

merci pour ton retour

Mince j’ai raté cet évolution dommage que l’on ne puisse pas choisir le cron 1, 5 ou 15 en fonction

Du coup, je pense que je vais carrément me passer du plugin. T° et charge à la minute (pour l’analyse ou 5 minute pour le quotidien), ça me va bien, j’ai pas vraiment besoin du reste…

image
Par contre jMQTT est pas copain avec les unités

1 « J'aime »
18

Se n’est qu un tag

Screenshot_2020-08-03-21-52-43-686
Screenshot_2020-08-03-21-52-43-6861920×1200 292 KB

1 « J'aime »
19

Bien vu, par contre c’est pour le widget customJauge… Avec celui par défaut, c’est dommage de ne pas utiliser les unités prévues par jeedom

image
image1685×114 9.24 KB

20

Pour palier un manque temporaire
Ça marche si le widget core|perso possède le tag dans son code
Screenshot_2020-08-03-21-54-07-365-1
Screenshot_2020-08-03-22-07-03-366-1

Si le tag n’y est pas via css personnalisation
After