API et info de la charge CPU

[jjacques68]

Hello tout le monde, 

 

on connait tous le graphique de charge du CPU du notre box : 

 

 

Je me pose la question suivante :

 

Comment il sortent les % ??

 

Dans l'API "diagnostics" on ne trouve que : 

{
      "name": "cpu0",
      "user": "9243",
      "nice": "0",
      "system": "7611",
      "idle": "99314"
},

Pas de %  

du coup, pour le calcul c'est quoi ??

(system) * 100 / idle

c'est le seul truc qui se rapproche un peu des % affichées  

 

merci d'avance !!

 

[Lazer]

Tu peux regarder la méthode de calcul dans les QA suivants :

 

 

 

 

[jjacques68]

merci @Lazer !

 

donc visiblement, d'après, le QA diagnostics c'est : 

(user+nice+system)*100/(user+nice+system+idle)

 

[Lazer]

Je n'ai pas vérifié les formules de @mprinfo, mais attention, il faut calculer le delta en faisant la soustraction avec les valeurs précédentes... ce qui implique que ton QA doit mémoriser les valeurs à chaque passage de boucle.

[jjacques68]

ben justement !?

je me demandait pourquoi il fallait faire ce calcul avec Delta ??

pourquoi cela ne marche pas à l'instant t ?

Par exemple interroger toutes les 5 secondes et voir l'évolution à l'instant t !

 

on a une répartition entre le user, le système et le non-utilisé !!

Je comprends pas l'intérêt de mémoriser le n-1 et de faire la différence !

 

y a peut-être un truc que j'ai pas compris alors ?

[Lazer]

En monitoring système, ça n'a pas de sens de regarder à un instant T, parce qu'une ça dure une microseconde, donc tu rates ce qui se passe pendant les 99,99999999999% du temps restant qu'il s'est écoulé depuis la dernière fois que tu as regardé.

 

Ce que tu donnes l'API, ce sont les métriques systèmes au niveau de l'OS (noyau Linux).

Pour simplifier, il compte le temps passé dans chaque "tâche"

Sachant que idle est un cas particulier, c'est le temps passé à ne rien faire

Et il faut soustraire la valeur précédente afin de calcul le delta CPU consommé

 

De cette façon, tu ne "rates" pas ce qui s'est passé entre 2 périodes de monitoring.

Enfin, c'est vite dit, parce que si tu regardes 1 fois toutes les 10 secondes, mais que le CPU a bossé 1s à 100% et le reste à 0, toi tu auras l'impression qu'il a bossé à 10% en moyenne pendant les 10s. Mais au moins, tu auras vu ces 10%, c'est toujours mieux que 0.

 

 

Au fait, attention, le calcul est à faire pour tous les cœurs du CPU de la box (4 sur HC3, 2 sur HC3L), il faut donc faire une petite boucle.

Regarde le code de mon QA DomoCharts, dont voici un extrait :

local diagnostics = api.get("/diagnostics")
local nbCPUs = #diagnostics.cpuLoad
if not self.cpuLoad then
	self.cpuLoad = {}
end
local cpuAverage = 0
-- Parse cores
for i = 1, nbCPUs do
	local cpuNew = diagnostics.cpuLoad[i]
	local cpuName = cpuNew.name
	local cpuOld = self.cpuLoad[cpuName]
	if cpuOld then
		local cpuTotalOld = (cpuOld.user + cpuOld.nice + cpuOld.system + cpuOld.idle)
		local cpuTotalNew = (cpuNew.user + cpuNew.nice + cpuNew.system + cpuNew.idle)
		local cpuPercentage = tools:round(((cpuTotalNew - cpuTotalOld) - (cpuNew.idle - cpuOld.idle)) / (cpuTotalNew - cpuTotalOld) * 100, 2)
		cpuAverage = cpuAverage + cpuPercentage
		print("Core #" .. i .. " " .. cpuName .. " = " .. cpuPercentage .. "%")
	end
	-- Memorize values
	self.cpuLoad[cpuName] = {
		user   = cpuNew.user,
		nice   = cpuNew.nice,
		system = cpuNew.system,
		idle   = cpuNew.idle,
	}
end
print("Usage CPU moyen sur la période : " .. (cpuAverage / nbCPUs))

 

Modifié le 2 août 2021 par Lazer

[jjacques68]

oké !!!

merci pour les explications !

je faisais fausse route là..

 

l'idée était de voir se qu'il se passe les très rares fois où la HC3 freeze.

je pensais développer une application tierce qui récupère les infos des CPU à coup de requête http, afin de les stocker en base et donc pouvoir les exploiter.

Je voulais le faire depuis une application extérieure justement pour ces freeze...

 

Pas sûr de les voir passer depuis un QA... si ça freeze, le QA est dans les choux aussi.

avec l'application extérieures, je pourrais tracer la non réponse de la requête, et voir si ça coïncide avec ce que j'observe !

[Lazer]

Si ça freeze, tu as tout autant de chance que l'API freeze également, comme le QA.

Donc ça ne changera rien.

 

Et que ça freeze n'est pas un souci, puisque tu mesures le delta justement. L’intervalle de temps sera allongé, et c'est tout. Mais tu mesureras bien la surconsommation CPU liée au freeze.

 

Reste le bon point de l'application externe qui passe par l'API : détecter et noter l'heure du freeze.

 

Sinon tu sais qu'en 10 minutes tu pourrais mettre en place DomoCharts sur un NAS et avoir la courbe CPU

 

Modifié le 2 août 2021 par Lazer

[Barelle]

C'est facile à réaliser avec Node-Red  :

 

[jjacques68]

il y a 8 minutes, Lazer a dit :

puisque tu mesures le delta justement

oui je comprend l'intérêt du delta maintenant, bien vu !!

 

il y a 9 minutes, Lazer a dit :

Sinon tu sais qu'en 10 minutes tu pourrais mettre en place DomoCharts sur un NAS et avoir la courbe CPU 

 tout à fait @Lazer !

Mais tu sais que j'aime faire moi même  quand je peux...

Même si je réinvente la roue... 

Le plaisir de passer des heures à coder...  

[Lazer]

C'est beau quand même Node RED.

 

Mais je me vois pas gérer 200 règles en mode graphique.... je suis surement déformé (mode Unixien), mais je trouve tellement plus facile de gérer 200 règles GEA en mode texte dans mon éditeur favori...
 

[Barelle]

Le sujet du topic n'est pas GEA...

 

Je répondais à @jjacques68 pour une application externe.

 

Même si  je préfère le LUA au Javascript, il n'empêche que, pour des fonctions simples, Node-RED est bien commode et d'une rare puissance

[jjacques68]

@Barelle, je ne connais pas du tout...

Suis plutôt axé windev, vu que je l'utilise énormément au boulo...

[Barelle]

Sans doute l'opportunité de découvrir une autre approche de la gestion des flux dans une approche plus XXIe siècle.

[jjacques68]

Alors voilà j'ai fini (avec webdev )

et j'ai exactement ce que je voulais voir !!

 

 

Freeze complet de la box à 20:53:25 !!

Aucun log qui remonte, aucun message d'erreurs nul part !!

 

J'ai 2 QA qui doivent travailler à cette heure-là ! Dont un qui tourne en boucle...

Donc ma recherche de bug est plutôt assez ciblé  

Sauf que comme dit, j'ai rien qui dit quoi que ce soit 

 

Est-il possible qu'un QA qui plante, fasse freezer la box, et qu'on ne le sache pas ?

Et visiblement celui qui tourne en boucle ne s'est pas relancé tout seul !? - je croyais que les QA redémarrait tout seul !

[Lazer]

Je ne sais pas....

Ta box n'a pas rebooté à ce moment là ?

 

Sinon un QA est redémarré tout seul quand il crashe.

Mais s'il s'arrête à cause d'une erreur de logique dans le code LUA, alors ce n'est pas un crash, donc il ne sera pas redémarré.

[jjacques68]

Il y a 4 heures, Lazer a dit :

Ta box n'a pas rebooté à ce moment là ?

non, en tous cas j'ai pas eu les notifications comme quand elle reboote avec le backup auto.

 

Il y a 4 heures, Lazer a dit :

Mais s'il s'arrête à cause d'une erreur de logique dans le code LUA

Ben y a rien qui m'arrête cette loop sauf si je vais manuellement mettre la QA (type binary) sur false.

 

C'est de nouveau bien tordu mon histoire...

J'ai mis du debug partout, j'ai testé à la mano, tout fonctionne, on verra ce soir en condition automatique...

Mais franchement j'ai un doute...

[jjacques68]

alors :

 

ce soir, à nouveau un freeze de 3 minutes. mais bien plus tard que les précédents.

A un moment où absolument rien devait se produire !

Donc on peut pas dire que ça vient de mes 2 QA cités plus haut... (ça m'arrange  )

 

Mais alors que ce passe-t-il ?

 

qqun à la possibilité de vérifier un éventuel freeze chez lui, à moment x de la journée ?

[Lazer]

Justement j'ai eu un freeze hier, à 7h33 du matin.

Aucune activité particulière dans la maison, pas de mouvement, rien, les QA qui font leurs jobs habituel sans plus (boucles infinies)

 

J'ai vérifié tous les logs de mes QA, aucun signe, si ce n'est que les boucles ont été décalées car retardées par le freeze.

C'est pas dit que ça vienne d'un QA, ça peut être un autre événement dans la box... process interne, flooding sur le réseau Z-Wave, un process qui interroge un service cloud qui ne répond pas... va savoir

[jjacques68]

étrange oui...

la durée du freeze, chez moi, est de 3 min.

Qui correspond à la durée du reboot effectué par l'auto backup.

Mais je confirme qu'elle ne reboote pas à ce moment !! (j'ai pas les log)

 

il y a 2 minutes, Lazer a dit :

process interne, flooding sur le réseau Z-Wave, un process qui interroge un service cloud qui ne répond pas... 

ok, mais, si ça arrive quand une action doit être réalisée, ben cette action, on peut juste l'oublier !!

dans le cas de la fermeture des volets le soir, ça crains  !!!

 

va falloir doubler le déclenchement des scénarios par sécurité séparé par x temps ? - nan mais là on y arrive plus !!

[Lazer]

Ah oui c'est long, chez moi c'était plutôt de l'ordre d'une à 2 minutes.

 

C'est là que je me dis que GEA est super, car pour les actions qui se déclenchent à intervalle régulier, j'ai pris l'habitude depuis la HC2 (sur laquelle les freeze pouvaient aussi se produire) de mettre une plage horaire de 2 minutes minimum, donc tant que l'action n'est pas effectuée, GEA va la lancer du moment qu'on est toujours dans la plage donnée.

Du coup, pour tes scénarios, il faut que tu programmes une plage et non pas une heure fixe.

[jjacques68]

Il y a 1 heure, Lazer a dit :

Du coup, pour tes scénarios, il faut que tu programmes une plage et non pas une heure fixe.

bien vu ça !!

 

mais il faut un flag pour dire que l'action a été traité, pour ne pas la refaire dans la même plage...

 

EDIT : ou peut-être encore mieux : une queue liste d'action à faire... ben non !! ça changera rien au problème... 

Modifié le 20 août 2021 par jjacques68

[Lazer]

Oui c'est ça, il faut marquer l'action une fois qu'elle a été effectuée (chose que fait GEA nativement, forcément, c'est son mode de fonctionnement de base).

Tu vas encore t'amuser à coder en LUA

 

[jjacques68]

c'est bon je suis dedans là !!!

motivé  motivé  

 

et puis plein le c... de travailler avec des variable de "type" heure (ex : "07:30"), je passe aux timestamp, beaucoup plus simple à exploiter...

[jjacques68]

il y a une heure, Lazer a dit :

Oui c'est ça, il faut marquer l'action une fois qu'elle a été effectuée

bon, chose faite  

 

curieux de voir ce que ça donnera ce soir...  

Du coup j'ai mis 5 minutes de delta pour la plage, c'est beaucoup je trouve...

ça veut dire aussi que le réveil du matin peut se mettre en route 5 minutes après l'heure programmée  

bon... vaut mieux ça que rien du tout  ça m'était jamais arrivé encore...

Modifié le 20 août 2021 par jjacques68