Chasse à la charge CPU

J’ai l’impression que selon ton graph que quand tu es absent la charge est moindre.
Par conséquent cela est lié a des scénario quand tu es présent.

Cela doit te mettre sur la piste.

Avec quoi tu graph le CPU ?

Salut,

J’ai aussi eu cette impression aussi mais le lien n’est pas évident/systématique :

  • j’ai assez peu de scénario qui se désactivent pendant mes absences
  • Les volets sont toujours pilotés
  • Le pilotage du chauffage (zwave) est coupé

En fait j’ai surtout l’impression que le plugin monitoring (celui qui fait le load du CPU/Mémoire etc) ne remonte pas des valeurs forcement toutes représentatives… Mais c’est déjà c’est nettement moindre aujourd’hui : bug ou ancienne install pourrie, ou effet des quelques changements (blea que j’ai viré par exemple)

En comparaison avec le script python qui mesure le % du cpu (toute distance gardée c’est pas exactement les même mesures), ça donne ça…



La les comportements sont normaux à mon sens…

Bref, je vais modifier le script python pour remonter les mêmes valeurs que le plugin Monitoring, ça permettra de voir plus clair…

@MrJuJu0319, @ajja17orange et @bartounet
Bon, je vais pourvoir mieux suivre et comparer (il y a pê une coquille sur le disque, à checker)

image

2 « J'aime »

on reviens à la normal

ti n’utilises pas de script ssh ?

C’est le python qui lance quelques commandes shell et poste côté mqtt

non pour autre besoin ?

un script ssh n’a pas de time out
sauf lancer derrier du PHP ou en intégrant dans le script une vérification.

donc si tu lances des script ssh
et que tu n’as pas de réponse il reste en process (d’où le ctrl-c avec putty pour mettre fin)
et à chaque lancement 1 utilisation inutile qui a force sature ta charge.

python je ne sais pas.

Non ça j’utilise pas

Maintenant que le script python tourne bien je peux comparer les valeurs (en orange) avec les infos issues du plugin monitoring (en bleu)

  • C’est bien plus précis avec le python (en même temps c’est l’objectif 1er)
  • Soit c’est pas de bol et sur quasi 30h, le plugin est toujours tombé sur LE pic d’activité lors de sa mesure, soit le plugin est ultra gourmand et consomme 50% à lui seul au moment de la mesure…

Et comme l’évoque @ajja17orange, effectivement, ça doit coûter cher quand il faut passer par du ssh pour aller monitorer un autre pi distant, et encore plus en cas de plantage… MQTT semble bien plus adapté

Encore quelques modifs autour de l’usage des disques et j’utilise ça aussi pour le suivi du pi dédié à octoprint
image

1 « J'aime »