Edge-home-orchestration-go: Период обновления информации о ресурсах

Созданный на 1 сент. 2020  ·  7Комментарии  ·  Источник: lf-edge/edge-home-orchestration-go

Ваш запрос функции связан с проблемой?
В настоящее время интервал обновления информации о ресурсах составляет 5 секунд, а точность слишком низкая.
Ниже приведен журнал того, когда пограничная оркестровка постоянно получала запросы на разгрузку службы. (см. время и 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

Все 7 Комментарий

@ t25kim Спасибо за интересное предложение. (Возможно, я прав или ошибаюсь, поэтому, пожалуйста, поправьте меня ^^) Обновление на основе событий и / или какой-либо механизм динамического обновления (временного интервала) всегда выглядит ценным. Дело в том, как мы могли бы интегрировать эту идею в существующий edge-home-orchestration-go . Кроме того, было бы интересно, если бы мы все вместе оценили какое-либо влияние использования памяти на запросы этих обновлений ресурсов с принятием этой идеи. У вас есть какие-нибудь идеи для начала?

@ Karthikeyan-Samsung @ suresh-lc Что вы думаете об этом предложении?

Снижение частоты повлияет на производительность устройства. Более того, алгоритм Scoring Manager необходимо доработать и основать на подходе машинного обучения (временные ряды, ARIMA и т. Д.).

На основе событий - хорошая идея, но нам нужно изучить возможность регистрации событий, которые показывают изменение ЦП / памяти. И мы должны попытаться сделать его универсальным, а не зависимым от оборудования. Как упоминал Картик, подход на основе временных рядов - хороший подход. Нам также необходимо провести мозговой штурм для получения данных для такого анализа. Это хорошее начало, и мы можем обсудить это подробнее.

В долгосрочной перспективе, как сказал @ Karthikeyan-Samsung, это правильно.
В краткосрочной перспективе, учитывая текущую ситуацию, я думаю, что информация о ресурсах должна обновляться динамически, изменяя текущее фиксированное время в 5 секунд.
Например, интервал в 5 секунд подойдет, если осталось мало ресурсов и информация верна. Однако мы должны серьезно подумать об интервале в противоположном случае (нехватка ресурсов и неверная информация), поскольку опасно говорить, что есть много доступных ресурсов, когда их мало.

@ suresh-lc @ Karthikeyan-Samsung @ t25kim Спасибо за все продуктивные и вдохновляющие предложения. Если нам нужны как краткосрочный, так и среднесрочный подходы для улучшения текущего механизма обновления ресурсов, есть ли какие-либо средства запуска для изменения временного интервала для обновления доступных ресурсов с edge-home-orchestrator-go ? ^^ Надеюсь получить хоть какое-нибудь хорошее представление об этом. (В конце концов, похоже, что это основано на Event-driven)

Я думаю, что StartMonitoringResource () может определять интервал с информацией о ресурсах в db и отправлять значение в качестве параметра для обновления информации о ресурсах.
Меня беспокоит порог и алгоритм определения интервала.

Я думаю, что StartMonitoringResource () может определять интервал с информацией о ресурсах в db и отправлять значение в качестве параметра для обновления информации о ресурсах.
Меня беспокоит порог и алгоритм определения интервала.

Похоже, это также связано с так называемым AI / ML, отражающим шаблон пользователя. Например, частое обновление в напряженное время и редко обновление в полночь или что-то в этом роде.

Так что я также хотел бы связать эту проблему с № 26.

Была ли эта страница полезной?
0 / 5 - 0 рейтинги