Edge-home-orchestration-go: Période de mise à jour des informations sur les ressources
Votre demande de fonctionnalité est liée à un problème ?
Actuellement, l'intervalle de mise à jour des informations sur les ressources est de 5 secondes et la précision est trop faible.
Ce qui suit est le journal des moments où l'orchestration Edge a régulièrement reçu des demandes de déchargement de service. (voir temps et cpuUsage)
2020/09/01 08:00:38 orchestration_api.go:421: candidate resource : map[cpuCount:8 cpuFreq:4200 cpuUsage:1.7456359102244388 netBandwidth:500 rtt:0.000816483]
2020/09/01 08:00:38 orchestration_api.go:421: candidate resource : map[cpuCount:8 cpuFreq:4200 cpuUsage:1.7456359102244388 netBandwidth:500 rtt:0.000816483]
2020/09/01 08:00:39 orchestration_api.go:421: candidate resource : map[cpuCount:8 cpuFreq:4200 cpuUsage:1.7456359102244388 netBandwidth:500 rtt:0.000816483]
2020/09/01 08:00:41 orchestration_api.go:421: candidate resource : map[cpuCount:8 cpuFreq:4200 cpuUsage:1.7456359102244388 netBandwidth:500 rtt:0.000816483]
2020/09/01 08:00:42 orchestration_api.go:421: candidate resource : map[cpuCount:8 cpuFreq:4200 cpuUsage:1.7456359102244388 netBandwidth:500 rtt:0.000816483]
2020/09/01 08:00:43 orchestration_api.go:421: candidate resource : map[cpuCount:8 cpuFreq:4200 cpuUsage:1.7456359102244388 netBandwidth:250 rtt:0.000425345]
2020/09/01 08:00:44 orchestration_api.go:421: candidate resource : map[cpuCount:8 cpuFreq:4200 cpuUsage:13.316582914572864 netBandwidth:250 rtt:0.000425345]
2020/09/01 08:00:44 orchestration_api.go:421: candidate resource : map[cpuCount:8 cpuFreq:4200 cpuUsage:13.316582914572864 netBandwidth:250 rtt:0.000425345]
2020/09/01 08:00:45 orchestration_api.go:421: candidate resource : map[cpuCount:8 cpuFreq:4200 cpuUsage:13.316582914572864 netBandwidth:250 rtt:0.000425345]
2020/09/01 08:00:46 orchestration_api.go:421: candidate resource : map[cpuCount:8 cpuFreq:4200 cpuUsage:13.316582914572864 netBandwidth:250 rtt:0.000425345]
2020/09/01 08:00:47 orchestration_api.go:421: candidate resource : map[cpuCount:8 cpuFreq:4200 cpuUsage:13.316582914572864 netBandwidth:250 rtt:0.000425345]
2020/09/01 08:00:47 orchestration_api.go:421: candidate resource : map[cpuCount:8 cpuFreq:4200 cpuUsage:13.316582914572864 netBandwidth:250 rtt:0.000425345]
2020/09/01 08:00:48 orchestration_api.go:421: candidate resource : map[cpuCount:8 cpuFreq:4200 cpuUsage:13.316582914572864 netBandwidth:250 rtt:0.000452635]
2020/09/01 08:00:49 orchestration_api.go:421: candidate resource : map[cpuCount:8 cpuFreq:4200 cpuUsage:13.316582914572864 netBandwidth:166 rtt:0.000452635]
2020/09/01 08:00:49 orchestration_api.go:421: candidate resource : map[cpuCount:8 cpuFreq:4200 cpuUsage:19.6405648267009 netBandwidth:166 rtt:0.000452635]
2020/09/01 08:00:50 orchestration_api.go:421: candidate resource : map[cpuCount:8 cpuFreq:4200 cpuUsage:19.6405648267009 netBandwidth:166 rtt:0.000452635]
2020/09/01 08:00:51 orchestration_api.go:421: candidate resource : map[cpuCount:8 cpuFreq:4200 cpuUsage:19.6405648267009 netBandwidth:166 rtt:0.000452635]
2020/09/01 08:00:52 orchestration_api.go:421: candidate resource : map[cpuCount:8 cpuFreq:4200 cpuUsage:19.6405648267009 netBandwidth:166 rtt:0.000452635]
2020/09/01 08:00:52 orchestration_api.go:421: candidate resource : map[cpuCount:8 cpuFreq:4200 cpuUsage:19.6405648267009 netBandwidth:166 rtt:0.000452635]
2020/09/01 08:00:53 orchestration_api.go:421: candidate resource : map[cpuCount:8 cpuFreq:4200 cpuUsage:19.6405648267009 netBandwidth:166 rtt:0]
2020/09/01 08:00:54 orchestration_api.go:421: candidate resource : map[cpuCount:8 cpuFreq:4200 cpuUsage:19.6405648267009 netBandwidth:166 rtt:0]
2020/09/01 08:00:54 orchestration_api.go:421: candidate resource : map[cpuCount:8 cpuFreq:4200 cpuUsage:19.6405648267009 netBandwidth:166 rtt:0]
2020/09/01 08:00:56 orchestration_api.go:421: candidate resource : map[cpuCount:8 cpuFreq:4200 cpuUsage:15.83011583011583 netBandwidth:333 rtt:0]
2020/09/01 08:00:57 orchestration_api.go:421: candidate resource : map[cpuCount:8 cpuFreq:4200 cpuUsage:15.83011583011583 netBandwidth:333 rtt:0]
2020/09/01 08:00:58 orchestration_api.go:421: candidate resource : map[cpuCount:8 cpuFreq:4200 cpuUsage:15.83011583011583 netBandwidth:333 rtt:0.000969224]
2020/09/01 08:00:59 orchestration_api.go:421: candidate resource : map[cpuCount:8 cpuFreq:4200 cpuUsage:15.83011583011583 netBandwidth:333 rtt:0.000969224]
2020/09/01 08:00:59 orchestration_api.go:421: candidate resource : map[cpuCount:8 cpuFreq:4200 cpuUsage:15.83011583011583 netBandwidth:333 rtt:0.000969224]
2020/09/01 08:01:00 orchestration_api.go:421: candidate resource : map[cpuCount:8 cpuFreq:4200 cpuUsage:15.83011583011583 netBandwidth:333 rtt:0.000969224]
2020/09/01 08:01:01 orchestration_api.go:421: candidate resource : map[cpuCount:8 cpuFreq:4200 cpuUsage:15.83011583011583 netBandwidth:333 rtt:0.000969224]
Décrivez la solution que vous souhaitez
Que diriez-vous de mettre à jour les informations sur les ressources pendant l'exécution du service (conteneur) ?
t25kim
Tous les 7 commentaires
@t25kim Merci pour la suggestion intéressante. (Peut-être que j'ai raison ou tort, alors corrigez-moi s'il vous plaît ^^) La mise à jour basée sur les événements et/ou un mécanisme de mise à jour dynamique (intervalle de temps) semble toujours utile. Le point est de savoir comment nous pourrions intégrer cette idée dans le edge-home-orchestration-go existant. De plus, il pourrait être intéressant que nous évaluions tous ensemble l'impact de l'empreinte mémoire sur la demande de mises à jour de ressources avec l'adoption de cette idée. Avez-vous une autre idée pour commencer?
@Karthikeyan-Samsung @suresh-lc Que pensez-vous de cette proposition ?
MoonkiHong
le 1 sept. 2020
La réduction de la fréquence aura un impact sur les performances de l'appareil. De plus, l'algorithme de Scoring Manager doit être affiné et basé sur une approche ML (Time Series, ARIMA etc...)
Karthikeyan-Samsung
le 1 sept. 2020
Basé sur les événements est une bonne idée, mais nous devons explorer l'enregistrement pour les événements qui montrent un changement CPU/Mémoire. Et nous devrions essayer de le rendre générique plutôt que dépendant du matériel. Comme mentionné par Karthik, les séries chronologiques sont une bonne approche. Nous devons également réfléchir à des données pour une telle analyse. C'est un bon début et nous pouvons en discuter davantage.
suresh-lc
le 1 sept. 2020
À long terme, il est juste d'y aller comme l'a dit @Karthikeyan-Samsung.
À court terme, compte tenu de la situation actuelle, je pense que les informations sur les ressources devraient être mises à jour dynamiquement en modifiant le temps actuellement fixé de 5 secondes.
Par exemple, un intervalle de 5 secondes convient s'il reste peu de ressources et que les informations sont correctes. Cependant, il faut penser sérieusement à l'intervalle dans le cas contraire (manque de ressource et information erronée) car il est dangereux de dire qu'il y a beaucoup de ressources disponibles alors qu'il y a peu de ressources disponibles.
t25kim
le 2 sept. 2020
@suresh-lc @Karthikeyan-Samsung @t25kim Merci pour toutes les suggestions productives et inspirantes. Si nous avons besoin à la fois des approches à court et moyen-long terme pour améliorer le mécanisme actuel de mise à jour des ressources, existe-t-il des moyens de déclenchement pour modifier l'intervalle de temps pour mettre à jour les ressources disponibles à partir de edge-home-orchestrator-go ? ^^ J'espère avoir une bonne idée à ce sujet. (En fin de compte, il semble être basé sur Event-driven)
MoonkiHong
le 2 sept. 2020
Je pense que StartMonitoringResource() peut déterminer l'intervalle avec les informations sur les ressources dans la base de données et envoyer la valeur en tant que paramètre pour mettre à jour les informations sur les ressources.
Ma préoccupation est le seuil et l'algorithme pour déterminer l'intervalle.
t25kim
le 3 sept. 2020
Je pense que StartMonitoringResource() peut déterminer l'intervalle avec les informations sur les ressources dans la base de données et envoyer la valeur en tant que paramètre pour mettre à jour les informations sur les ressources.
Ma préoccupation est le seuil et l'algorithme pour déterminer l'intervalle.
Il semble que cela soit également lié à ce que l'on appelle le modèle des utilisateurs reflétant l'IA/ML. Comme une mise à jour fréquente pendant les heures de pointe, et rarement une mise à jour à minuit ou quelque chose comme ça.
Donc, j'aimerais aussi lier ce problème avec #26 .
MoonkiHong
le 17 sept. 2020
Questions connexes
MoonkiHong
·
6Commentaires
MoonkiHong
·
5Commentaires
DoomsdayT
·
3Commentaires
t25kim
·
5Commentaires
t25kim
·
3Commentaires