Edge-home-orchestration-go: संसाधन सूचना अद्यतन अवधि

को निर्मित 1 सित॰ 2020 · 7टिप्पणियाँ · स्रोत: lf-edge/edge-home-orchestration-go

क्या आपका फीचर अनुरोध किसी समस्या से संबंधित है?
वर्तमान में, संसाधन सूचना अद्यतन अंतराल 5 सेकंड है और सटीकता बहुत कम है।
एज ऑर्केस्ट्रेशन को लगातार सेवा ऑफलोड अनुरोध प्राप्त होने पर लॉग निम्न है। (समय और सीपीयू उपयोग देखें)

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 में कैसे एकीकृत कर सकते हैं। इसके अलावा, यह दिलचस्प हो सकता है अगर हम सभी इस विचार को अपनाने के साथ उन संसाधन अद्यतनों के अनुरोध पर स्मृति पदचिह्न के किसी भी प्रभाव का अनुमान लगाते हैं। क्या आपके पास शुरू करने के लिए कोई और विचार है?

@ कार्तिकेयन-सैमसंग @ सुरेश-एलसी आप इस प्रस्ताव के बारे में क्या सोचते हैं?

MoonkiHong 1 सित॰ 2020

👍1

आवृत्ति को कम करने से डिवाइस के प्रदर्शन पर असर पड़ेगा इसके अलावा स्कोरिंग मैनेजर एल्गोरिदम को परिष्कृत करने और एमएल दृष्टिकोण (टाइम सीरीज़, एआरआईएमए इत्यादि ...) के आधार पर परिष्कृत करने की आवश्यकता है।

Karthikeyan-Samsung 1 सित॰ 2020

👍1

घटना आधारित अच्छा विचार है, लेकिन हमें उन घटनाओं के पंजीकरण के लिए पता लगाने की जरूरत है जो सीपीयू/मेमोरी परिवर्तन दिखाते हैं। और हमें इसे हार्डवेयर पर निर्भर होने के बजाय सामान्य बनाने की कोशिश करनी चाहिए। जैसा कि कार्तिक ने उल्लेख किया है, समय श्रृंखला आधारित अच्छा दृष्टिकोण है। हमें इस तरह के विश्लेषण के लिए भी डेटा के लिए मंथन करने की जरूरत है। यह अच्छी शुरुआत है और हम इस पर और चर्चा कर सकते हैं।

suresh-lc 1 सित॰ 2020

👍1

लंबे समय में, @ कार्तिकेयन-सैमसंग ने कहा कि जाना सही है।
अल्पावधि में, वर्तमान स्थिति को देखते हुए, मुझे लगता है कि वर्तमान में 5 सेकंड के निश्चित समय को बदलकर संसाधन जानकारी को गतिशील रूप से अद्यतन किया जाना चाहिए।
उदाहरण के लिए, यदि कुछ संसाधन बचे हैं और जानकारी सही है तो 5 सेकंड का अंतराल ठीक है। हालांकि, हमें विपरीत स्थिति (संसाधन की कमी और गलत जानकारी) में अंतराल के बारे में गंभीरता से सोचना चाहिए क्योंकि यह कहना खतरनाक है कि कुछ उपलब्ध संसाधन होने पर कई संसाधन उपलब्ध हैं।

t25kim 2 सित॰ 2020

👍1

@ सुरेश-एलसी @ कार्तिकेयन-सैमसंग @ t25kim सभी उपयोगी और प्रेरक सुझावों के लिए धन्यवाद। यदि हमें वर्तमान संसाधन अद्यतन तंत्र में सुधार के लिए लघु और मध्य-दीर्घकालिक दोनों दृष्टिकोणों की आवश्यकता है, तो क्या उपलब्ध संसाधनों को edge-home-orchestrator-go से अद्यतन करने के लिए समय अंतराल को संशोधित करने के लिए कोई ट्रिगरिंग साधन है? ^^ इस बारे में कोई अच्छा विचार प्राप्त करने की आशा है। (अंत में, यह घटना-संचालित पर आधारित प्रतीत होता है)

MoonkiHong 2 सित॰ 2020

👍1

मुझे लगता है कि StartMonitoringResource() डीबी में संसाधन जानकारी के साथ अंतराल निर्धारित कर सकता है और संसाधन जानकारी को अद्यतन करने के लिए मान को पैरामीटर के रूप में भेज सकता है।
मेरी चिंता अंतराल निर्धारित करने के लिए दहलीज और एल्गोरिदम है।

t25kim 3 सित॰ 2020

👍1

मुझे लगता है कि StartMonitoringResource() डीबी में संसाधन जानकारी के साथ अंतराल निर्धारित कर सकता है और संसाधन जानकारी को अद्यतन करने के लिए मान को पैरामीटर के रूप में भेज सकता है।
मेरी चिंता अंतराल निर्धारित करने के लिए दहलीज और एल्गोरिदम है।

ऐसा लगता है कि यह तथाकथित एआई/एमएल से संबंधित है जो उपयोगकर्ताओं के पैटर्न को दर्शाता है। जैसे व्यस्त समय के दौरान बार-बार अपडेट करना, और शायद ही कभी आधी रात के दौरान अपडेट करना या ऐसा ही कुछ।

इसलिए, मैं इस मुद्दे को #26 से भी जोड़ना चाहूंगा।

MoonkiHong 17 सित॰ 2020

क्या यह पृष्ठ उपयोगी था?

0 / 5 - 0 रेटिंग्स

Edge-home-orchestration-go: संसाधन सूचना अद्यतन अवधि

सभी 7 टिप्पणियाँ

संबंधित मुद्दों