Edge-home-orchestration-go: Período de actualización de la información de recursos
¿Su solicitud de función está relacionada con un problema?
Actualmente, el intervalo de actualización de la información de recursos es de 5 segundos y la precisión es demasiado baja.
El siguiente es el registro de cuándo Edge Orchestration recibió constantemente solicitudes de descarga de servicios. (ver tiempo y 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]
Describe la solución que te gustaría
¿Qué hay de actualizar la información de recursos mientras se ejecuta el servicio (contenedor)?
t25kim
Todos 7 comentarios
@ t25kim Gracias por la interesante sugerencia. (Tal vez esté en lo correcto o equivocado, así que corríjame ^^) La actualización basada en eventos y / o algún mecanismo de actualización dinámica (intervalo de tiempo) siempre parece valioso. El punto es cómo podríamos integrar esta idea en el edge-home-orchestration-go . Además, podría ser interesante si todos juntos estimamos el impacto de la huella de memoria en la solicitud de actualizaciones de recursos con la adopción de esta idea. ¿Tiene alguna idea más para empezar?
@ Karthikeyan-Samsung @ suresh-lc ¿Qué opinas de esta propuesta?
MoonkiHong
en 1 sept. 2020
La reducción de la frecuencia afectará el rendimiento del dispositivo.Además, el algoritmo de Scoring Manager debe refinarse y basarse en el enfoque de ML (Time Series, ARIMA, etc.)
Karthikeyan-Samsung
en 1 sept. 2020
Basado en eventos es una buena idea, pero necesitamos explorar para registrar eventos que muestren cambios de CPU / memoria. Y deberíamos intentar hacerlo genérico en lugar de dependiente del hardware. Como mencionó Karthik, las series de tiempo basadas en un buen enfoque. También necesitamos hacer una lluvia de ideas para obtener datos para dicho análisis. Este es un buen comienzo y podemos discutir más sobre esto.
suresh-lc
en 1 sept. 2020
A largo plazo, es correcto ir como dijo @ Karthikeyan-Samsung.
A corto plazo, considerando la situación actual, creo que la información del recurso debería actualizarse dinámicamente cambiando el tiempo actualmente fijo de 5 segundos.
Por ejemplo, un intervalo de 5 segundos está bien si quedan pocos recursos y la información es correcta. Sin embargo, deberíamos pensar seriamente en el intervalo en el caso contrario (falta de recurso e información incorrecta) ya que es peligroso decir que hay muchos recursos disponibles cuando hay pocos recursos disponibles.
t25kim
en 2 sept. 2020
@ suresh-lc @ Karthikeyan-Samsung @ t25kim Gracias por todas las sugerencias productivas e inspiradoras. Si necesitamos los enfoques a corto y mediano plazo para mejorar el mecanismo de actualización de recursos actual, ¿existe algún medio de activación para modificar el intervalo de tiempo para actualizar los recursos disponibles desde edge-home-orchestrator-go ? ^^ Espero tener una buena idea sobre esto. (Al final, parece estar basado en eventos impulsados)
MoonkiHong
en 2 sept. 2020
Creo que StartMonitoringResource () puede determinar el intervalo con la información del recurso en la base de datos y enviar el valor como parámetro para actualizar la información del recurso.
Mi preocupación es el umbral y el algoritmo para determinar el intervalo.
t25kim
en 3 sept. 2020
Creo que StartMonitoringResource () puede determinar el intervalo con la información del recurso en la base de datos y enviar el valor como parámetro para actualizar la información del recurso.
Mi preocupación es el umbral y el algoritmo para determinar el intervalo.
Parece que esto también está relacionado con el llamado AI / ML que refleja el patrón de los usuarios. Como actualizaciones frecuentes durante la hora punta, y rara vez se actualizan durante la medianoche o algo así.
Entonces, también me gustaría vincular este problema con el n. ° 26.
MoonkiHong
en 17 sept. 2020
Temas relacionados
t25kim
·
4Comentarios
t25kim
·
3Comentarios
MoonkiHong
·
4Comentarios
t25kim
·
5Comentarios
t25kim
·
3Comentarios