2010-11-03 15 views
7

मैं नेटवर्क पर डिवाइस प्रबंधित करने वाले कार्यों को लागू करने के लिए संभावित रूप से सैकड़ों धागे के उपयोग पर विचार कर रहा हूं।सैकड़ों निष्क्रिय धागे का प्रभाव

यह एक सी ++ एप्लिकेशन है जो एक लिनक्स कर्नेल के साथ एक पावरपीसी प्रोसेसर पर चल रहा है।

प्रारंभिक चरण के बाद जब प्रत्येक कार्य डिवाइस से डेटा को डेटा में कॉपी करने के लिए सिंक्रनाइज़ेशन करता है, तो कार्य निष्क्रिय हो जाता है, और केवल अलार्म प्राप्त होने पर ही जागता है, या कुछ डेटा (कॉन्फ़िगरेशन) को बदलने की आवश्यकता होती है, जो कि है प्रारंभ चरण के बाद दुर्लभ। एक बार सभी कार्य "निष्क्रिय" चरण तक पहुंचने के बाद, मुझे उम्मीद है कि प्रति सेकंड केवल कुछ ही जागने की आवश्यकता होगी।

तो, मेरी मुख्य चिंता यह है कि, अगर मेरे पास सैकड़ों धागे हैं तो वे निष्क्रिय होने के बाद सिस्टम पर नकारात्मक प्रभाव डालेंगे?

धन्यवाद।

amso

संपादित करें:
मैं जवाब है कि मुझे मिल गया के आधार पर सवाल अद्यतन करने कर रहा हूँ। धन्यवाद दोस्तों। तो ऐसा लगता है कि धागे के एक टन (आईओ अवरुद्ध, प्रतीक्षा, सो, इत्यादि), प्रति से, प्रतिक्रिया के संदर्भ में सिस्टम पर कोई प्रभाव नहीं पड़ेगा। बेशक , वे एक धागा के ढेर और TLS डेटा के लिए अतिरिक्त पैसे खर्च होगा, लेकिन है कि लंबे समय के रूप ठीक है के रूप में हम बात पर अधिक स्मृति फेंक (जिससे यह अधिक €€€)

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

अंत में, सैकड़ों धागे का पूरा विचार जो अधिकतर निष्क्रिय हो जाएगा, को थ्रेड पूल की तरह मॉडलिंग किया जा सकता है। इससे कुछ कोड रैखिकता कम हो जाती है लेकिन नाटकीय रूप से समाधान की स्केलेबिलिटी बढ़ जाती है और प्रोपर्स केयर के साथ प्रदर्शन और संसाधन उपयोग के बीच समझौता समायोजित करने के लिए आसानी से ट्यून करने योग्य हो सकता है।

मुझे लगता है कि इतना ही है। उनके इनपुट के लिए सभी को धन्यवाद।

-
amso

+3

यदि आपको सैकड़ों धागे की आवश्यकता है, तो आप गलत तरीके से समस्या को देख रहे हैं। –

+4

रोजर: मैं असहमत हूं, समस्या के आधार पर 100 धागे ठीक हो सकते हैं। धागे का उपयोग करना मतलब है कि कोड एक रैखिक अच्छा हो सकता है, जो कुछ कार्यों को अधिक आसान बनाता है। – MarkR

+0

मैं असहमति से असहमत हूं। यदि आपने कभी लिनक्स पर 'ps amx' आउटपुट देखा है, तो आप कुछ प्रोग्राम (जैसे ...' console-kit-daemon') देखेंगे जो लगभग 63 डेमॉन थ्रेड रखेगा (जिनमें से 57 आम तौर पर बेकार हैं और कुछ भी नहीं करते हैं)। – user562374

उत्तर

8

प्रत्येक धागा भूमि के ऊपर है - सबसे महत्वपूर्ण बात यह हर एक का अपना ढेर और TLS है। प्रदर्शन इतना समस्या नहीं है क्योंकि उन्हें कोई भी समय स्लाइस नहीं मिलेगा जब तक कि वे वास्तव में कुछ भी नहीं करते। आप अभी भी थ्रेड पूल का उपयोग करने पर विचार करना चाह सकते हैं।

+0

चाहे "निष्क्रिय" धागे समय स्लाइस का उपयोग करेंगे या नहीं, उनके कोड को कैसे लिखा जाता है। उदाहरण के लिए, मैंने बहुत सारे "निष्क्रिय" कोड को देखा जो केवल हर कई एमएस जांचता है कि उसे कुछ करना है या नहीं। – valdo

+3

ओच :) हाँ, "निष्क्रिय" द्वारा, मेरा मतलब एक प्रतीक्षा राज्य में एक धागा था, न कि "प्रोग्रामर निष्क्रिय साधनों को क्या सोचता है"। – EboMike

+1

"निष्क्रिय" से मेरा मतलब है कि थ्रेड एक सेमफोर पर अवरुद्ध होगा या प्रतीक्षा की स्थिति तक प्रतीक्षा करेगा जब तक कि कुछ बाहरी गतिविधि नहीं होती है जिसके लिए इसके हस्तक्षेप की आवश्यकता होती है।उदाहरण के लिए: एक पैकेट टाइम आउट, एक पैकेट प्राप्त हुआ, कुछ डेटा बदल दिया और सिंक करने की आवश्यकता है ... – amso

1

मैं एक लिनक्स हैकर नहीं कर रहा हूँ, लेकिन यह सोचते हैं कि लिनक्स के धागे शेड्यूलिंग विंडोज 'के समान है ...

हाँ, के पाठ्यक्रम कुछ प्रभाव नहीं पड़ेगा। आपके द्वारा उपयोग की जाने वाली प्रत्येक स्मृति में संभावित रूप से कुछ प्रभाव होंगे।

हालांकि, एक समय-कटा हुआ वातावरण में, प्रतीक्षा/नींद/जुड़ने वाले राज्य में मौजूद थ्रेड सीपीयू चक्र का उपभोग नहीं करेंगे जब तक वे जागृत न हों।

+1

मुझे विश्वास है कि हाल के संस्करणों में, लिनक्स धागे बहुत हल्के हैं। Http://en.wikipedia.org/wiki/Native_POSIX_Thread_Library, और esp देखें। डिजाइन पेपर जो संदर्भित है। –

+0

@Steve मैंने कई वेबसाइटों पर पढ़ा है (और मुझे लगता है कि लिनक्स कर्नेल को समझने में भी, हालांकि मैं उस पर गलत हो सकता हूं) कि पठ्रेड यूनिक्स पर प्रक्रियाओं के रूप में कार्यान्वित किए जाते हैं, इसलिए यह वास्तव में भारी है। दरअसल, आपका लिंक कहता है कि अब भी मैं इसे देखता हूं। –

2

मैं 1: 1 थ्रेड-कनेक्शन मैपिंग की पेशकश करने के बारे में चिंतित हूं, अगर कुछ और नहीं है क्योंकि यह आपको सेवा हमलों से इनकार करने के बजाय उजागर करता है।

EboMike पहले से ही सीधे सवाल का जवाब है (pthread_create() एक काफी महंगा आपरेशन accept() करने के लिए सिर्फ एक फोन की तुलना में) - प्रदान की धागे ब्लॉक किए गए हैं और व्यस्त इंतजार कर रहे हैं तो वे संसाधनों के रास्ते में ज्यादा उपभोग नहीं होगा नहीं, हालांकि वे सभी प्रति-थ्रेड राज्य के लिए स्मृति और स्वैप पर कब्जा करेगा।

+0

सलाह के लिए धन्यवाद। डीओएस जोखिम नहीं है क्योंकि आने वाले कनेक्शन के आधार पर धागे बनाए/नष्ट नहीं होते हैं। इसके बजाए, जब वे किसी डिवाइस को हटाए जाते हैं तो नष्ट हो जाते हैं और डिवाइस को हटा दिए जाने पर नष्ट होने पर एप्लिकेशन को कॉन्फ़िगर किया जाता है (इसके निष्पादन के दौरान)। – amso

+0

क्या आप मेरे उत्तर की जांच कर सकते हैं और मुझे अपने विचार बता सकते हैं? मुझे लगता है कि धागा जागने में विलंबता की स्वीकार्यता के आधार पर एक प्रभाव हो सकता है। –

3

मुख्य रूप से वे पता स्थान और ढेर के लिए स्मृति का उपयोग करेंगे; एक बार जब आप कहते हैं, 1000 धागे, यह काफी महत्वपूर्ण हो जाता है क्योंकि मैंने देखा है कि प्रति थ्रेड 10 एम स्टैक्स के लिए सामान्य है (x86_64 पर)। यह परिवर्तनीय है, लेकिन केवल देखभाल के साथ।

यदि आपके पास 32-बिट प्रोसेसर है, तो थ्रेड के 1000s को मारने के बाद पता स्थान मुख्य सीमा होगी, आप आसानी से एएस को समाप्त कर सकते हैं।

वे कुछ कर्नेल मेमोरी का उपयोग करते हैं, लेकिन शायद उपयोगकर्ता स्थान जितना अधिक नहीं।


संपादित करें: निश्चित रूप से धागे एक दूसरे के साथ पता स्थान साझा करते हैं, यदि वे एक ही प्रक्रिया में हैं; मुझे लगता है कि वे हैं।

+0

pthread लाइब्रेरी में 32 मेगाबाइट प्रति थ्रेड की सिफारिश की गई न्यूनतम – Jay

+3

उद्धरण कृपया; मैंने देखा है कि ज्यादातर सिस्टम लगभग 1 एम - 8 एम पर डिफ़ॉल्ट लगते हैं; मैं नहीं देख सकता कि प्रति थ्रेड 32 एमबी न्यूनतम की सिफारिश की जाती है। – MarkR

0

मैं अब कर्नेल की मूल बातें सीख रहा हूं। मैं आपको अभी तक एक विशिष्ट जवाब नहीं दे सकता; मैं अभी भी एक नोब हूँ ... लेकिन यहां कुछ चीजें हैं जिन पर आप चबाते हैं।

लिनक्स प्रत्येक POSIX थ्रेड को एक अद्वितीय प्रक्रिया के रूप में लागू करता है। अन्य लोगों ने उल्लेख किया है कि यह ओवरहेड बना देगा। इसके अतिरिक्त, आपका प्रतीक्षा मॉडल किसी भी तरह से त्रुटिपूर्ण दिखाई देता है। यदि आप प्रत्येक थ्रेड के लिए एक सशर्त चर बनाते हैं, तो मुझे लगता है (नीचे दी गई वेबसाइट की मेरी व्याख्या के आधार पर) कि आप वास्तव में बहुत सारी कर्नेल मेमोरी का विस्तार करेंगे, क्योंकि प्रत्येक थ्रेड को अपनी प्रतीक्षा कतार में रखा जाएगा। यदि इसके बजाय आप एक्स थ्रेड के प्रत्येक समूह के लिए एक सशर्त चर साझा करने के लिए अपने धागे को तोड़ते हैं, तो आपको समस्याएं भी मिलती हैं क्योंकि हर बार परिवर्तनीय सिग्नल, आपको उस चर के प्रतीक्षा कतार में _EVERY_DARN_PROCESS_ को जागृत करना होगा।

मुझे यह भी लगता है कि आपको कुछ ऑब्जेक्ट को सिंक्रनाइज़ेशन साझा करने की आवश्यकता होगी। इस मामले में, संसाधन के इंतजार की सभी प्रक्रियाओं को जागृत करने की आवश्यकता के कारण आपका कोड धीमा हो सकता है, जैसा कि मैंने पहले उल्लेख किया था।

मुझे पता है कि यह बहुत मदद नहीं थी, लेकिन जैसा कि मैंने कहा, मैं कर्नेल नोब हूं। उम्मीद है कि यह थोड़ा सा मदद की।

http://book.chinaunix.net/special/ebook/PrenticeHall/PrenticeHallPTRTheLinuxKernelPrimer/0131181637/ch03lev1sec7.html

+0

एनपीटीएल कार्यान्वयन की मेरी समझ यह है कि "हर धागा एक प्रक्रिया है" शुरू में आधा जितना बुरा नहीं है, क्योंकि इस मानचित्र को क्लोन कॉल करने के बजाय काफी अनुकूलित किया जाता है। बेंचमार्क इस से सहमत हैं (http://kerneltrap.org/node/429)। जहां तक ​​प्रति थ्रेड एक सशर्त चर हो जाता है, यदि वास्तव में इसकी आवश्यकता होती है और समस्या हो जाती है तो आप इसके आसपास "हैशिंग" (यानी साझा करना) 1 cond var प्रति 20 धागे या इससे भी काम कर सकते हैं। मैं यह मान रहा था कि आईओओ थ्रेड को अवरुद्ध कर देगा जो सिंक्रनाइज़ेशन प्राइमेटिव नहीं है जो मुझे लगता है कि यह भी सस्ता है। – Flexo

+0

सिंक्रनाइज़ेशन का उपयोग करके थ्रेड अवरोधन किया जाना है। एक सेमफोर एक हल्का समाधान होगा? धागे की जागने और अवरुद्ध आसानी से निर्माता-उपभोक्ता पैटर्न की तरह मॉडलिंग किया जा सकता है। – amso

+0

इसे मापें और देखें। मुझे लगता है कि लिनक्स पर अधिकांश पाथ्रेड सिंक्रनाइज़ेशन प्राइमेटिव्स इन दिनों futex (2) का उपयोग करके लागू किए गए हैं, इसलिए शायद उनके बीच बहुत अंतर नहीं है। अगर उन्हें फ्यूटेक्स का उपयोग करके लागू नहीं किया गया है तो आप इसे स्वयं का उपयोग करने से कुछ प्रदर्शन लाभ देख सकते हैं हालांकि मैं दृढ़ता से इसे मापने का सुझाव देता हूं। – Flexo

0

मुझे यकीन है कि क्या "डिवाइस" आप के बारे में बात कर रहे हैं नहीं कर रहा हूँ, लेकिन अगर यह एक फ़ाइल वर्णनकर्ता है, मैं सुझाव देंगे कि आप या तो चुनाव या epoll उपयोग करने के लिए स्थानांतरित करने के लिए शुरू करने को देखने के (ईद का सुझाव उत्तरार्द्ध ने वर्णन किया कि आप प्रत्येक फाइल डिस्क्रिप्टर की अपेक्षा कितनी सक्रिय हैं)। इस तरह, आप एक प्रक्रिया का उपयोग कर सकते हैं जो सभी एफडीएस के लिए जिम्मेदार होगा।

+0

धन्यवाद। मुझे लगता है कि आपने सवाल को गलत समझा। मैं एक फाइल डिस्क्रिप्टर और न ही किसी भी प्रकार की घटनाओं से मतदान नहीं कर रहा हूं। प्रश्न संभावित रूप से सैकड़ों उपकरणों या संस्थाओं, या किसी भी राज्य के एल्गोरिदम की आवश्यकता के नियंत्रण के लिए कई कार्यों के कार्यान्वयन से संबंधित है। – amso

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