jjacques68 Posté(e) le 2 août 2021 Signaler Posté(e) le 2 août 2021 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 Posté(e) le 2 août 2021 Signaler Posté(e) le 2 août 2021 Tu peux regarder la méthode de calcul dans les QA suivants :
jjacques68 Posté(e) le 2 août 2021 Auteur Signaler Posté(e) le 2 août 2021 merci @Lazer ! donc visiblement, d'après, le QA diagnostics c'est : (user+nice+system)*100/(user+nice+system+idle)
Lazer Posté(e) le 2 août 2021 Signaler Posté(e) le 2 août 2021 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 Posté(e) le 2 août 2021 Auteur Signaler Posté(e) le 2 août 2021 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 Posté(e) le 2 août 2021 Signaler Posté(e) le 2 août 2021 (modifié) 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 Posté(e) le 2 août 2021 Auteur Signaler Posté(e) le 2 août 2021 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 Posté(e) le 2 août 2021 Signaler Posté(e) le 2 août 2021 (modifié) 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 1
Barelle Posté(e) le 2 août 2021 Signaler Posté(e) le 2 août 2021 C'est facile à réaliser avec Node-Red : 1
jjacques68 Posté(e) le 2 août 2021 Auteur Signaler Posté(e) le 2 août 2021 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... 1
Lazer Posté(e) le 2 août 2021 Signaler Posté(e) le 2 août 2021 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... 1
Barelle Posté(e) le 2 août 2021 Signaler Posté(e) le 2 août 2021 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 Posté(e) le 2 août 2021 Auteur Signaler Posté(e) le 2 août 2021 @Barelle, je ne connais pas du tout... Suis plutôt axé windev, vu que je l'utilise énormément au boulo...
Barelle Posté(e) le 2 août 2021 Signaler Posté(e) le 2 août 2021 Sans doute l'opportunité de découvrir une autre approche de la gestion des flux dans une approche plus XXIe siècle. 2
jjacques68 Posté(e) le 17 août 2021 Auteur Signaler Posté(e) le 17 août 2021 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 Posté(e) le 18 août 2021 Signaler Posté(e) le 18 août 2021 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 Posté(e) le 18 août 2021 Auteur Signaler Posté(e) le 18 août 2021 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 Posté(e) le 19 août 2021 Auteur Signaler Posté(e) le 19 août 2021 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 Posté(e) le 19 août 2021 Signaler Posté(e) le 19 août 2021 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 Posté(e) le 19 août 2021 Auteur Signaler Posté(e) le 19 août 2021 é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 Posté(e) le 20 août 2021 Signaler Posté(e) le 20 août 2021 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 Posté(e) le 20 août 2021 Auteur Signaler Posté(e) le 20 août 2021 (modifié) 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 Posté(e) le 20 août 2021 Signaler Posté(e) le 20 août 2021 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 Posté(e) le 20 août 2021 Auteur Signaler Posté(e) le 20 août 2021 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 Posté(e) le 20 août 2021 Auteur Signaler Posté(e) le 20 août 2021 (modifié) 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
Messages recommandés