खैर, या लगभग सभी ...

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

लेख में मैं यह दिखाने की कोशिश करूंगा कि एपोल और अन्य तंत्रों के बीच मूलभूत अंतर क्या है, यह अद्वितीय क्या है, साथ ही साथ उन लेखों का भी उल्लेख करता है जिन्हें आपको केवल एपोल की संभावनाओं और समस्याओं को समझने के लिए पढ़ने की आवश्यकता है।

कोई भी एक कुल्हाड़ी मार सकता है, लेकिन यह एक सच्चा योद्धा लेता है जो इसे मेले की धुन गाता है।

मुझे लगता है कि पाठक एपोल से परिचित है, कम से कम मैन पेज पढ़ें। एपोल , पोल , सेलेक्ट के बारे में पर्याप्त लिखा गया है ताकि लिनक्स के तहत विकसित होने वाले हर व्यक्ति ने कम से कम एक बार इसके बारे में सुना हो।

बहुत से एफ.डी.

जब लोग एपोल के बारे में बात करते हैं, तो मैं मूल रूप से इस बात को सुनता हूं कि जब बहुत सारे फ़ाइल डिस्क्रिप्टर होते हैं तो इसका प्रदर्शन बेहतर होता है।

बस एक सवाल पूछना चाहता हूँ - कितना है? कितने कनेक्शनों की आवश्यकता है, और सबसे महत्वपूर्ण बात यह है कि किन परिस्थितियों में, मूर्त प्रदर्शन लाभ देना शुरू हो जाएगा?

उन लोगों के लिए जिन्होंने एपोल का अध्ययन किया (वैज्ञानिक लेखों सहित काफी सामग्री है), उत्तर स्पष्ट है - यह बेहतर है अगर और केवल "एक घटना की प्रतीक्षा" यौगिकों की संख्या "प्रसंस्करण के लिए तैयार" की संख्या से अधिक हो। मात्रा का चिह्न, जब लाभ इतना महत्वपूर्ण हो जाता है कि इस तथ्य को अनदेखा करने के लिए बस कोई मूत्र नहीं होता है, 10k यौगिकों को माना जाता है [4]।

अधिकांश कनेक्शन लंबित होने की धारणा ध्वनि तर्क और सर्वर के लोड मॉनिटरिंग से आती है जो सक्रिय उपयोग में हैं।

यदि सक्रिय यौगिकों की संख्या कुल संख्या के लिए प्रयास करती है, ~~कोई लाभ नहीं होगा~~ कोई महत्वपूर्ण लाभ नहीं होगा, एक महत्वपूर्ण लाभ केवल और केवल इसलिए है क्योंकि एपोल केवल विवरणदाताओं को ध्यान देने की आवश्यकता है, और उन सभी विवरणों को प्रदूषित करता है जो अवलोकन के लिए जोड़े गए थे।

जाहिर है, बाद के मामले में, हम कर्नेल से घटनाओं की एक सरणी की नकल करने के सभी डिस्क्रिप्टर + ओवरहेड को पार करने में समय व्यतीत करते हैं।

वास्तव में, प्रारंभिक प्रदर्शन माप में, जो पैच [9] से जुड़ा था, इस बिंदु को रेखांकित नहीं किया गया है और एक केवल लेख में उल्लिखित डीकॉन उपयोगिता की उपस्थिति से अनुमान लगा सकता है (दुर्भाग्य से, pipetest.c उपयोगिता कोड खो गया है)। दूसरी ओर, अन्य स्रोतों में [६, notice] यह ध्यान नहीं देना बहुत मुश्किल है, क्योंकि यह तथ्य व्यावहारिक रूप से बाहर है।

सवाल तुरंत उठता है, लेकिन अब क्या होगा अगर इस तरह के कई एपोल फाइल डिस्क्रिप्टर को सेवा देने की योजना नहीं है, जैसा कि यह था, और इसकी आवश्यकता नहीं है?

इस तथ्य के बावजूद कि एपोल मूल रूप से ऐसी स्थितियों के लिए विशेष रूप से बनाया गया था [5, 8, 9], यह एपोल के बीच एकमात्र अंतर से बहुत दूर है।

EPOLLET

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

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

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

यदि लेवल-ट्रिगर व्यवहार में एपोल (साथ ही पोल / सेलेक्ट ) को अनलॉक किया जाता है, यदि डिस्क्रिप्टर निर्दिष्ट स्थिति में है और इस स्थिति के साफ़ होने तक सक्रिय माना जाएगा, तो एज-ट्रिगर केवल वर्तमान दिए गए राज्य को बदलकर अनलॉक किया गया है।

यह आपको बाद में घटना को संभालने की अनुमति देता है, और रसीद पर तुरंत नहीं (लगभग एक सीधा सादृश्य के साथ ऊपरी आधा और नीचे के आधे हिस्से में बाधा हैंडलर)।

एपोल के साथ विशिष्ट उदाहरण:

स्तर बढ़ गया

ध्वज EPOLLIN के साथ एपोल में जोड़ा गया
घटना के लिए प्रतीक्षा करते समय epoll_wait () ब्लॉक
19 डिस्क्रिप्टर फ़ाइल बाइट को लिखें
epoll_wait () EPOLLIN इवेंट के साथ अनलॉक होता है
हम उस डेटा के साथ कुछ नहीं करते हैं जो आया था
epoll_wait () EPOLLIN इवेंट के साथ फिर से अनलॉक होता है

और यह तब तक जारी रहेगा जब तक हम डिस्क्रिप्टर से डेटा को पूरी तरह से गिन या रीसेट नहीं करते हैं।

बढ़त तेज हो गई

EPOLLIN झंडे के साथ जोड़ने के लिए जोड़ा गया हैंडल | EPOLLET
घटना के लिए प्रतीक्षा करते समय epoll_wait () ब्लॉक
19 डिस्क्रिप्टर फ़ाइल बाइट को लिखें
epoll_wait () EPOLLIN इवेंट के साथ अनलॉक होता है
हम उस डेटा के साथ कुछ नहीं करते हैं जो आया था
epoll_wait () अवरुद्ध है एक नई घटना की प्रतीक्षा में
फ़ाइल डिस्क्रिप्टर पर एक और 19 बाइट्स लिखें
epoll_wait () नए EPOLLIN इवेंट के साथ अनलॉक होता है
epoll_wait () अवरुद्ध है एक नई घटना की प्रतीक्षा में

सरल उदाहरण: epollet_socket.c

इस तंत्र को पहले से संसाधित किए जा रहे ईवेंट के कारण epoll_wait () की वापसी को रोकने के लिए डिज़ाइन किया गया है।

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

EPOLLET ही घटनाओं के लिए एपोल O (1) को बहुसंकेतक बनाता है।

ईगैन और ईपीओएलईटी के बारे में व्याख्या करना आवश्यक है - ईगैन के साथ सिफारिश बाइट-स्ट्रीम का इलाज करने के लिए नहीं है, बाद वाले मामले में खतरा केवल तभी उठता है जब आपने विवरणकर्ता को अंत तक नहीं पढ़ा था, और नया डेटा नहीं आया था। फिर डिस्क्रिप्टर में पूंछ लटक जाएगी, लेकिन आपको एक नया नोटिफिकेशन नहीं मिलेगा। स्वीकार () के साथ, स्थिति बस अलग है, आपको तब तक जारी रखना चाहिए जब तक कि स्वीकार नहीं हो जाता () रिटर्न ईएजीएन , केवल इस मामले में सही संचालन की गारंटी है।

// TCP socket (byte stream) //  fd    EPOLLIN      int len = read(fd, buffer, BUFFER_LEN); if(len < BUFFER_LEN) { //   } else { //         //  -       epoll_wait, //      }

  // accept //  listenfd    EPOLLIN      event.events = EPOLLIN | EPOLLERR; epoll_ctl(epoll_fd, EPOLL_CTL_ADD, server_fd, &event); sleep(5); //       >1  //   while(epoll_wait()) { newfd = accept(listenfd, ...); //      //        //  epoll_wait    listenfd    } //   while(epoll_wait()) { while((newfd = accept(...)) > 0) { //  -  } if(newfd == -1 && errno = EAGAIN) { //       //       } }

इस संपत्ति के साथ, बस भुखमरी काफी है:

पैकेट विवरणक के पास आते हैं
बफर को पैकेट पढ़ें
एक और पैकेट आता है
बफर को पैकेट पढ़ें
एक छोटा सा हिस्सा आता है
...

इस प्रकार , हम जल्द ही ईएजीएन प्राप्त नहीं करेंगे, लेकिन हम इसे प्राप्त नहीं कर सकते हैं।

इस प्रकार, अन्य फ़ाइल डिस्क्रिप्टर को प्रोसेसिंग के लिए समय नहीं मिलता है, और हम लगातार पढ़ने में व्यस्त हैं, डेटा के छोटे हिस्से।

गरजनदार बेवकूफ झुंड

अंतिम ध्वज पर जाने के लिए, आपको यह समझने की आवश्यकता है कि यह वास्तव में क्यों बनाया गया था और प्रौद्योगिकी और सॉफ्टवेयर के विकास के साथ डेवलपर्स के लिए क्या समस्याएं पैदा हुईं।

झुंड समस्या का समाधान

थंडर हर्ड की समस्या

एक घटना की प्रतीक्षा कर रहे प्रक्रियाओं की एक बड़ी संख्या की कल्पना करें। यदि कोई घटना होती है, तो वे जाग जाएंगे और संसाधनों के लिए संघर्ष शुरू हो जाएगा, हालांकि केवल एक प्रक्रिया की आवश्यकता है जो घटना के आगे के प्रसंस्करण से निपटेंगे। बाकी प्रक्रियाएं फिर से सो जाएंगी।

आईटी शब्दावली - वसीली अलेक्सेन्को

इस मामले में, हम स्वीकार करने की समस्या में रुचि रखते हैं () और पढ़ें () एपोल के साथ संयोजन में धाराओं पर वितरित की जाती हैं।

स्वीकार करना

दरअसल, स्वीकार करने के लिए एक अवरुद्ध कॉल के साथ (), लंबे समय से कोई समस्या नहीं है। कर्नेल ध्यान रखेगा कि इस घटना के लिए केवल एक प्रक्रिया को अनलॉक किया गया है, और सभी आने वाले कनेक्शन क्रमबद्ध हैं।

लेकिन एपोल के साथ , ऐसी चाल काम नहीं करेगी। यदि हम गैर-ब्लॉकिंग सॉकेट पर बनाए गए सुनो () हैं , तो कनेक्शन स्थापित होने पर, सभी epoll_wait () इस विवरणक से घटना की प्रतीक्षा करेंगे।

बेशक, स्वीकार () केवल एक धागा करने में सक्षम होगा, बाकी को ईगैन प्राप्त होगा, लेकिन यह संसाधनों की बर्बादी है।

इसके अलावा, EPOLLET भी हमारी मदद नहीं करता है, क्योंकि हम यह नहीं जानते कि कनेक्शन कतार ( बैकलॉग ) में कितने कनेक्शन हैं। जैसा कि हम याद करते हैं, EPOLLET का उपयोग करते समय , सॉकेट प्रसंस्करण तब तक जारी रहना चाहिए जब तक कि यह ईएजीएन त्रुटि कोड के साथ वापस नहीं आ जाता है, इसलिए एक मौका है कि सभी स्वीकार () एक धागा द्वारा संसाधित किए जाएंगे और बाकी को काम नहीं मिलेगा।

और यह फिर से हमें एक ऐसी स्थिति में ले जाता है, जहां पड़ोसी धारा व्यर्थ हो गई थी।

हम एक अलग प्रकार की भुखमरी भी प्राप्त कर सकते हैं - हमारे पास केवल एक धागा लोड होगा, और बाकी को प्रसंस्करण के लिए कनेक्शन नहीं मिलेगा।

EPOLLONESHOT

संस्करण 4.5 से पहले, एक गैर-अवरुद्ध श्रवण () डिस्क्रिप्टर में अगले स्वीकार () कॉल के साथ वितरित एपोल को संसाधित करने का एकमात्र सही तरीका EPOLLONESHOT ध्वज सेट करना था, जिसके कारण हमें एक बार में केवल एक थ्रेड में संसाधित होने के लिए स्वीकार करना पड़ा ।

संक्षेप में - अगर EPOLLONESHOT का उपयोग किया जाता है , तो एक विशेष विवरणक के साथ जुड़ी घटना केवल एक बार ही आग लग जाएगी, जिसके बाद epoll_ctl () का उपयोग करके झंडे को फिर से मुर्गा करना आवश्यक है।

EPOLLEXCLUSIVE

यहाँ EPOLLEXCLUSIVE और स्तर-ट्रिगर हमारी सहायता के लिए आता है।

EPOLLEXCLUSIVE एक घटना के लिए एक समय में एक लंबित epoll_wait () को अनलॉक करता है।

यह योजना काफी सरल है (वास्तव में नहीं):

हमारे पास एन थ्रेड्स हैं जो एक कनेक्शन ईवेंट का इंतजार कर रहे हैं
पहला क्लाइंट हमसे जुड़ता है
थ्रेड 0 बिखरेगा और प्रसंस्करण शुरू होगा, अन्य धागे अवरुद्ध रहेंगे
एक दूसरा क्लाइंट हमसे जुड़ता है, यदि थ्रेड 0 अभी भी प्रोसेसिंग में व्यस्त है, तो थ्रेड 1 अनलॉक किया गया है
हम आगे जारी रखते हैं जब तक कि थ्रेड पूल समाप्त नहीं हो जाता है (कोई भी epoll_wait () पर एक घटना की उम्मीद नहीं करता है)
एक और ग्राहक हमसे जुड़ रहा है
और इसके प्रसंस्करण को पहला धागा प्राप्त होगा, जिसे epoll_wait () कहा जाएगा।
दूसरे थ्रेड को दूसरा क्लाइंट प्राप्त होगा, जो epoll_wait () कॉल करेगा

इस प्रकार, सभी रखरखाव समान रूप से प्रवाह में वितरित किए जाते हैं।

 $ ./epollexclusive --help -i, --ip=ADDR specify ip address -p, --port=PORT specify port -n, --threads=NUM specify number of threads to use #    -  n*8 -t, --thunder not adding EPOLLEXCLUSIVE #     thunder herd -h, --help prints this message $ sudo taskset -c 0-7 ./epollexclusive -i 10.56.75.201 -p 40000 -n 8 2>&1

उदाहरण कोड: epollexclusive.c (केवल 4.5 से कर्नेल संस्करण के साथ काम करेगा)

हमें एपोल पर प्री-फोर्क मॉडल मिलता है। यह योजना कम समय के टीसीपी कनेक्शन के लिए अच्छी तरह से लागू है।

पढ़ना

लेकिन बाइट-स्ट्रीमिंग के मामले में रीड () के साथ, EPOLLCL की तरह EPOLLEXCLUSIVE हमारी मदद नहीं करेगा।

स्पष्ट कारणों के लिए, EPOLLEXCLUSIVE के बिना हम सभी स्तर पर ट्रिगर नहीं कर सकते। EPOLLEXCLUSIVE के साथ , सब कुछ बेहतर नहीं है, क्योंकि हम धाराओं के ऊपर एक पैकेज फैल सकते हैं, इसके अलावा बाइट्स का एक अज्ञात क्रम आ गया है।

EPOLLET के साथ , स्थिति समान है।

और यहाँ काम पूरा होने पर पुनर्निमाण के साथ EPOLLONESHOT का रास्ता होगा। इसलिए, जैसे ही एक थ्रेड इस फाइल डिस्क्रिप्टर और बफर के साथ काम करेगा:

EPOLLONESHOT झंडे के साथ जोड़ने के लिए हैंडल | EPOLLET
epoll_wait पर प्रतीक्षा ()
सॉकेट से बफर तक पढ़ें () रिटर्न ईएएनजीएन
EPOLLONESHOT झंडों के साथ फिर से बनाइए | EPOLLET

संरचना epoll_event

 typedef union epoll_data { void *ptr; int fd; uint32_t u32; uint64_t u64; } epoll_data_t; struct epoll_event { uint32_t events; /* Epoll events */ epoll_data_t data; /* User data variable */ };

यह आइटम शायद मेरे लेख मेरे व्यक्तिगत IMHO में केवल एक है। सूचक या संख्या का उपयोग करने की क्षमता सहायक है। उदाहरण के लिए, एपोल का उपयोग करते समय पॉइंटर का उपयोग करने से आप इस तरह से एक ट्रिक कर सकते हैं:

 #define container_of(ptr, type, member) ({ \ const typeof( ((type *)0)->member ) *__mptr = (ptr); \ (type *)( (char *)__mptr - offsetof(type,member) );}) struct epoll_client { /** some usefull associated data...*/ struct epoll_event event; }; struct epoll_client* to_epoll_client(struct epoll_event* event) { return container_of(event, struct epoll_client, event); } struct epoll_client ec; ... epoll_ctl(efd, EPOLL_CTL_ADD, fd, &ec.e); ... epoll_wait (efd, events, 1, -1); struct epoll_client* ec_ = to_epoll_client(events[0].data.ptr);

मुझे लगता है कि हर कोई जानता है कि यह तकनीक कहां से आई है।

निष्कर्ष

मुझे उम्मीद है कि हम एपोल के विषय को खोलने में सक्षम थे। जो लोग इस तंत्र का उपयोग जानबूझकर करना चाहते हैं, उन्हें केवल संदर्भ [1, 2, 3, 5] की सूची में लेख पढ़ने की आवश्यकता है।

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

एपोल अद्वितीय तंत्रों में से एक है, जिसे लोगों ने अपने लिनक्स प्रोग्रामिंग पथों को चुना है, उन्हें जानने की जरूरत है, क्योंकि वे अन्य ऑपरेटिंग सिस्टम पर एक गंभीर लाभ देते हैं), और, संभवतः, किसी विशेष मामले के लिए क्रॉस-प्लेटफ़ॉर्मिंग को मना कर देंगे (इसे काम करने दें) केवल लिनक्स पर लेकिन यह अच्छा होगा)।

समस्या की "विशिष्टता" के बारे में तर्क देना

इससे पहले कि कोई इन झंडे और उपयोग पैटर्न की विशिष्टता के बारे में बात करे, मैं एक प्रश्न पूछना चाहता हूं:

"लेकिन क्या यह कुछ भी नहीं है कि हम तंत्र के लिए विशिष्टता पर चर्चा करने की कोशिश कर रहे हैं जो विशिष्ट कार्यों के लिए शुरू में बनाई गई थी [9, 11]? या क्या हम 1k कनेक्शन भी सेवा करते हैं एक प्रोग्रामर के लिए एक दैनिक कार्य है?"

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

संदेह के लिए, कुछ लिंक:

NGINX 1.9.1 - VBart में SO_REUSEPORT के साथ बढ़ता प्रदर्शन
यूनिकॉर्न से सीखना: स्वीकार करना () गरजना गैर-समस्या - क्रिस सिएबेनमैन
सीरियलाइज़िंग स्वीकार (), AKA थंडरिंग हेर, AKA द ज़ीग प्रॉब्लम - रॉबर्टो डी इओरिस
एपोल के EPOLLEXCLUSIVE मोड स्तर-ट्रिगर के साथ कैसे बातचीत करता है?

संदर्भ

मानक

एपोल का विकास

उपसंहार

मूल्यवान चर्चाओं, टिप्पणियों और मदद के लिए सर्गेई ( dlinyj ) और पीटर ओवेचनकोव को बहुत धन्यवाद!

Linux epoll के बारे में पूरी सच्चाई