Edge-home-orchestration-go: 资源信息更新周期
您的功能请求是否与问题有关？
目前资源信息更新间隔为5秒，精度太低。
以下是 Edge Orchestration 持续收到服务卸载请求时的日志。 （见时间和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]
描述您想要的解决方案
在服务（容器）执行时更新资源信息如何？
enhancement
t25kim
所有7条评论
@t25kim谢谢你的有趣建议。 （也许我是对的或错的，所以请纠正我^^）基于事件的更新和/或一些动态更新（时间间隔）机制总是看起来很有价值。 关键是我们如何将这个想法整合到现有的edge-home-orchestration-go 。 另外，如果我们一起估计内存占用对采用这个想法请求这些资源更新的任何影响，可能会很有趣。 你有什么进一步的想法可以开始吗？
@Karthikeyan-Samsung @suresh-lc 你怎么看这个提议？
MoonkiHong
于 2020-09-01
👍1
降低频率会影响设备性能此外，需要改进评分管理器算法并基于 ML 方法（时间序列、ARIMA 等...）
Karthikeyan-Samsung
于 2020-09-01
👍1
基于事件是个好主意，但我们需要探索注册显示 CPU/内存变化的事件。 我们应该尝试使其通用而不是依赖于硬件。 正如 Karthik 所提到的，基于时间序列是一种很好的方法。 我们还需要为此类分析集思广益。 这是一个好的开始，我们可以就此进行更多讨论。
suresh-lc
于 2020-09-01
👍1
从长远来看，按照@Karthikeyan-Samsung 所说的去做是正确的。
短期来看，考虑到目前的情况，我认为应该通过改变当前固定的5秒时间来动态更新资源信息。
例如，如果剩余资源很少且信息正确，则间隔 5 秒就可以了。 但是，在相反的情况下（资源不足和信息不正确），我们应该认真考虑间隔，因为在可用资源很少的情况下说有很多可用资源是危险的。
t25kim
于 2020-09-02
👍1
@suresh-lc @Karthikeyan-Samsung @t25kim感谢您提出的所有富有成效和鼓舞人心的建议。 如果我们需要短期和中长期两种方法来改进当前的资源更新机制，是否有任何触发手段来修改从edge-home-orchestrator-go开始更新可用资源的时间间隔？ ^^ 希望对此有所了解。 （最后好像是基于Event-driven）
MoonkiHong
于 2020-09-02
👍1
我认为StartMonitoringResource()可以根据数据库中的资源信息确定间隔，并将该值作为参数发送以更新资源信息。
我关心的是阈值和确定间隔的算法。
t25kim
于 2020-09-03
👍1
我认为StartMonitoringResource()可以根据数据库中的资源信息确定间隔，并将该值作为参数发送以更新资源信息。
我关心的是阈值和确定间隔的算法。
看来这也和所谓的AI/ML反映用户的模式有关。 比如忙的时候经常更新，半夜很少更新之类的。
所以，我也想把这个问题与 #26 联系起来。
MoonkiHong
于 2020-09-17
此页面是否有帮助？
0 / 5 - 0 等级
相关问题
MoonkiHong
·
6评论
t25kim
·
5评论
t25kim
·
3评论
t25kim
·
5评论
MoonkiHong
·
7评论