Edge-home-orchestration-go: リソース情報の更新期間

作成日 2020年09月01日 · 7コメント · ソース: lf-edge/edge-home-orchestration-go

機能リクエストは問題に関連していますか？
現在、リソース情報の更新間隔は5秒であり、精度が低すぎます。
以下は、EdgeOrchestrationが一貫してサービスオフロード要求を受信したときのログです。（時間と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から更新するために時間間隔を変更するトリガー手段はありますか？ ^^これについて良いアイデアがあればいいのですが。（結局、それはイベント駆動型に基づいているようです）

MoonkiHong 2020年09月02日

👍1

StartMonitoringResource（）は、データベース内のリソース情報との間隔を決定し、リソース情報を更新するためのパラメーターとして値を送信する可能性があると思います。
私の懸念は、間隔を決定するためのしきい値とアルゴリズムです。

t25kim 2020年09月03日

👍1

StartMonitoringResource（）は、データベース内のリソース情報との間隔を決定し、リソース情報を更新するためのパラメーターとして値を送信する可能性があると思います。
私の懸念は、間隔を決定するためのしきい値とアルゴリズムです。

これは、ユーザーのパターンを反映したいわゆるAI / MLにも関連しているようです。忙しい時間帯に頻繁に更新するように、深夜などに更新することはめったにありません。

ですから、この問題を＃26とリンクさせたいと思います。

MoonkiHong 2020年09月17日

このページは役に立ちましたか？

0 / 5 - 0 評価

Edge-home-orchestration-go: リソース情報の更新期間

全てのコメント7件

関連する問題