2010-02-06 5 views
29

कई लिनक्स/यूनिक्स प्रोग्रामिंग पुस्तकें और ट्यूटोरियल "Thundering Herd Problem" के बारे में बात करते हैं जो तब होता है जब एक चयन सॉकेट की पठनीयता के लिए एक चुनिंदा() कॉल प्रतीक्षा पर कई धागे या कांटे अवरुद्ध होते हैं। जब कनेक्शन आता है, तो सभी धागे और कांटे जागृत होते हैं लेकिन "स्वीकार()" के लिए एक सफल कॉल के साथ केवल एक "जीतता है"। इस बीच, किसी भी कारण से सभी धागे/कांटे को जागने में बहुत सी सीपीयू समय बर्बाद हो जाता है।क्या लिंडरिंग हर्ड समस्या अब लिनक्स पर मौजूद है?

मैंने project देखा जो लिनक्स कर्नेल में इस समस्या के लिए "ठीक" प्रदान करता है, लेकिन यह एक बहुत पुराना पैच है।

मुझे लगता है कि दो प्रकार हैं; एक जहां प्रत्येक कांटा चयन() और फिर स्वीकार करता है(), और एक जो केवल स्वीकार करता है()।

क्या आधुनिक यूनिक्स/लिनक्स कर्नेल में अभी भी इन दोनों मामलों में केवल "चुनिंदा() स्वीकार करें()" संस्करण में थंडरिंग हर्ड समस्या है?

+1

इस कभी नहीं सुना है, लेकिन सामान का एक बहुत "लिनक्स कर्नेल बुरी तरह से करता है", निश्चित रूप से किसी भी अब सच नहीं है! –

+1

यह एक बहुत ही रोचक सवाल है। 'चयन' में 'अच्छी तरह से' स्वीकार करने के मामले में अच्छी तरह से संभालना वास्तव में कठिन होगा क्योंकि आप गारंटी नहीं दे सकते कि 'चयन' कर रही प्रक्रिया अंततः' स्वीकार करेगी '।मुझे लगता है कि किसी को पता लगाने के लिए एक परीक्षण चलाया जाना चाहिए, और शायद 'एपोल' का भी परीक्षण करें। – Omnifarious

उत्तर

9

सालों से, अधिकांश यूनिक्स/लिनक्स कर्नेल स्वीकार करते हैं (2) एस, दूसरे शब्दों में, केवल एक धागा जागृत हो जाता है यदि एक से अधिक खुले फ़ाइल विवरण के विरुद्ध स्वीकृति (2) पर अवरुद्ध हो रहा है।

ओटीओएच, कई (यदि नहीं सभी) कर्नेल के पास अभी भी चयन-स्वीकृति पैटर्न में गर्मी की समस्या है जो आप वर्णन करते हैं।

मैंने समस्या के अस्तित्व को सत्यापित करने के लिए एक साधारण स्क्रिप्ट (https://gist.github.com/kazuho/10436253) लिखा है, और पाया कि समस्या लिनक्स 2.6.32 और डार्विन 12.5.0 (ओएस एक्स 10.8.5) पर मौजूद है।

+0

संक्षिप्त परीक्षा के लिए धन्यवाद! संदर्भ के लिए, मैंने इसे लिनक्स 3.2.0-58 पर चुनिंदा स्वीकृति मोड में चलाने की कोशिश की: $ perl thundering-herd.pl कनेक्ट-स्वीकार्य स्वीकार करें! thundering-herd.pl लाइन 49. स्वीकृति विफल: संसाधन अस्थायी रूप से thundering-herd.pl लाइन 52 पर अनुपलब्ध है। - और 'स्वीकार' मोड में, कोई गरज नहीं है। – jdkoftinoff

+0

यह मुझे बताता है कि गर्मी की समस्याएं अभी भी मौजूद हैं और इसका मतलब यह है कि किसी को या तो सभी धागे चुनने के बिना स्वीकार कर सकते हैं() या एक धागा चुनने() और फिर स्वीकार करें() और फिर एफडी को पास करें प्रसंस्करण के लिए कार्यकर्ता धागा। – jdkoftinoff

+0

यह समस्या मेरे यूबंटू 8.04 (लिनक्स 2.6.24) – ASBai

10

यह एक बहुत पुरानी समस्या है, और अधिकांश भाग के लिए अब और मौजूद नहीं है। लिनक्स कर्नेल (पिछले कुछ वर्षों से) में नेटवर्क स्टैक को पैकेट को संभालने और मार्गों के साथ कई बदलाव हुए हैं, और कम विलंबता और निष्पक्षता सुनिश्चित करने के लिए कई अनुकूलन शामिल हैं (यानी भुखमरी को कम करें)।

उस ने कहा, सिस्टम का चयन करें इसके एपीआई के माध्यम से कई स्केलेबिलिटी समस्याएं हैं। जब आपके पास बड़ी संख्या में फ़ाइल डिस्क्रिप्टर हैं, तो एक चुनिंदा कॉल की लागत बहुत अधिक है। यह मुख्य रूप से सिस्टम कॉल से पास किए गए एफडी सेटों को बनाने, जांचने और बनाए रखने के कारण होता है।

अब दिन, एसिंक्रोनस आईओ करने का पसंदीदा तरीका एपोल के साथ है। एपीआई बहुत आसान है और विभिन्न प्रकार के लोड (कई कनेक्शन, थ्रूपुट, इत्यादि) में बहुत अच्छी तरह से स्केल करता है

+0

मैं उस स्थिति के बारे में सोच रहा हूं जहां प्रति कांटा केवल एक सॉकेट है और सॉकेट अवरुद्ध है। तो epoll() बनाम मतदान() बनाम चयन() यहां कोई फर्क नहीं पड़ता। क्या लिनक्स के पास अब सॉकेट सुनने के लिए विशेष कार्य जागने का व्यवहार है? – jdkoftinoff

+0

हां, आईआईआरसी, कार्यान्वयन अब केवल एक धागा उठता है (जैसा कि सभी धागे जागने और उन्हें प्रतिस्पर्धा करने के विपरीत है।) यह धागा कैसे चुनता है जटिल है, लेकिन सरल जवाब यह है: यह प्राथमिकता आधारित है, इसलिए यह निर्भर करता है निष्पक्षता बनाए रखने के लिए शेड्यूलर पर। किसी भी तरह, उस विशिष्ट जड़ी-बूटियों की समस्या अब मौजूद नहीं है, इसलिए स्थिति ओवरलोड पर उतनी ही गंभीर नहीं है। यह सब कहा, एपोल के बजाय चयन का उपयोग करने से उच्च CPU लागत (कर्नेल और उपयोगकर्ता-स्थान दोनों में) होती है, जो आईएमओ, आपके उपयोग-मामले के लिए नगण्य है। – 0xfe

+0

और क्या होता है यदि वह धागा 'स्वीकार' नहीं करता है? – Omnifarious

2

मैंने हाल ही में एक परिदृश्य का परीक्षण किया जहां कई धागे एक सुनवाई यूनिक्स-डोमेन सॉकेट पर मतदान करते थे और फिर स्वीकार करते थे कनेक्शन। सभी धागे मतदान() सिस्टम कॉल का उपयोग कर जाग गए।

यह एक डिस्ट्रो बिल्ड के बजाय लिनक्स कर्नेल का एक कस्टम निर्माण था, इसलिए शायद एक कर्नेल कॉन्फ़िगरेशन विकल्प है जो इसे बदलता है लेकिन मुझे नहीं पता कि यह क्या होगा।

हमने एपोल की कोशिश नहीं की।

2

नीचे दिए गए लिंक का संदर्भ लें जो इस समस्या से बचने के लिए अलग-अलग झंडे के बारे में बात करता है।

http://lwn.net/Articles/632590/

+1

और http://lwn.net/Articles/633422/ पर भी मौजूद है जो नए EPOLLEXCLUSIVE ध्वज के बारे में बात करता है ... –