Ваш запрос функции связан с проблемой?
В настоящее время интервал обновления информации о ресурсах составляет 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]
Опишите желаемое решение
Как насчет обновления информации о ресурсах во время выполнения службы (контейнера)?
@ 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.