Edge-home-orchestration-go: Periode Pembaruan Informasi Sumber Daya

Dibuat pada 1 Sep 2020  ·  7Komentar  ·  Sumber: lf-edge/edge-home-orchestration-go

Apakah permintaan fitur Anda terkait dengan masalah?
Saat ini, interval pembaruan informasi sumber daya adalah 5 detik dan akurasinya terlalu rendah.
Berikut ini adalah log saat Edge Orchestration secara konsisten menerima permintaan offload layanan. (lihat waktu dan 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]

Jelaskan solusi yang Anda inginkan
Bagaimana dengan memperbarui informasi sumber daya saat layanan (wadah) dijalankan?

enhancement

Semua 7 komentar

@t25kim Terima kasih atas saran yang menarik. (Mungkin saya benar atau salah, jadi tolong koreksi saya ^^) Pembaruan berbasis peristiwa dan/atau mekanisme pembaruan dinamis (interval waktu) selalu terlihat berharga. Intinya adalah bagaimana kita bisa mengintegrasikan ide ini ke dalam edge-home-orchestration-go . Plus, mungkin menarik jika kita bersama-sama memperkirakan dampak jejak memori pada permintaan pembaruan sumber daya tersebut dengan adopsi ide ini. Apakah Anda memiliki ide lebih lanjut untuk memulai?

@Karthikeyan-Samsung @suresh-lc Apa pendapat Anda tentang proposal ini?

Mengurangi frekuensi akan berdampak pada kinerja perangkat. Selain itu, algortima Scoring Manager perlu disempurnakan dan didasarkan pada pendekatan ML (Time Series, ARIMA dll...)

Berbasis acara adalah ide bagus, tetapi kita perlu mencari untuk mendaftar acara yang menunjukkan perubahan CPU/Memori. Dan kita harus mencoba membuatnya generik daripada bergantung pada perangkat keras. Seperti yang disebutkan oleh Karthik, berbasis time series adalah pendekatan yang baik. Kita perlu melakukan brainstorming untuk data untuk analisis semacam itu juga. Ini adalah awal yang baik dan kita dapat mendiskusikan lebih lanjut tentang ini.

Dalam pandangan panjang, itu benar untuk pergi seperti yang dikatakan @Karthikeyan-Samsung.
Dalam jangka pendek, mengingat situasi saat ini, saya pikir informasi sumber daya harus diperbarui secara dinamis dengan mengubah waktu tetap 5 detik.
Misalnya, interval 5 detik baik-baik saja jika hanya ada sedikit sumber daya yang tersisa dan informasinya benar. Namun, kita harus memikirkan interval dengan serius dalam kasus yang berlawanan (kurangnya sumber daya dan informasi yang salah) karena berbahaya untuk mengatakan bahwa ada banyak sumber daya yang tersedia ketika hanya ada sedikit sumber daya yang tersedia.

@suresh-lc @Karthikeyan-Samsung @t25kim Terima kasih atas semua saran yang produktif dan menginspirasi. Jika kita membutuhkan pendekatan jangka pendek dan menengah untuk meningkatkan mekanisme pembaruan sumber daya saat ini, apakah ada cara pemicu untuk mengubah interval waktu untuk memperbarui sumber daya yang tersedia dari edge-home-orchestrator-go ? ^^ Berharap untuk mendapatkan ide bagus tentang ini. (Pada akhirnya, tampaknya didasarkan pada Event-driven)

Saya pikir StartMonitoringResource() dapat menentukan interval dengan informasi sumber daya di db dan mengirim nilai sebagai parameter untuk memperbarui informasi sumber daya.
Kekhawatiran saya adalah ambang batas dan algoritma untuk menentukan interval.

Saya pikir StartMonitoringResource() dapat menentukan interval dengan informasi sumber daya di db dan mengirim nilai sebagai parameter untuk memperbarui informasi sumber daya.
Kekhawatiran saya adalah ambang batas dan algoritma untuk menentukan interval.

Sepertinya ini juga terkait dengan apa yang disebut AI/ML yang mencerminkan pola pengguna. Seperti sering update saat jam sibuk, dan jarang update saat tengah malam atau semacamnya.

Jadi, saya juga ingin menautkan masalah ini dengan #26 .

Apakah halaman ini membantu?
0 / 5 - 0 peringkat