टीएल; डीआर: क्या यह संभव है कि मैं रिएक्टर थ्रूपुट सीमित हूं? मैं कैसे बताऊंगा? कितना महंगा और स्केलेबल (धागे में) io_service का कार्यान्वयन है?बूस्ट एएसआईओ रिएक्टर से बचने के लिए कैसे एक कोर को बाध्य किया जा रहा है?
मेरे पास एक बड़े पैमाने पर समानांतर अनुप्रयोग है, जो एक हाइपरथ्रेडेड-डुअल-क्वाड-कोर-ज़ीऑन मशीन पर चल रहा है जिसमें बहुत सी रैम और तेज एसएसडी RAID है। यह boost :: asio का उपयोग करके विकसित किया गया है।
यह एप्लिकेशन लगभग 1,000 अन्य मशीनों से कनेक्शन स्वीकार करता है, डेटा पढ़ता है, एक साधारण प्रोटोकॉल डीकोड करता है, और एमएमएपी() का उपयोग करके मैप किए गए फ़ाइलों में डेटा को शफ़ल करता है। एप्लिकेशन मैडवाइस (विल्नेड) का उपयोग करके "भविष्य" एमएमएपी पृष्ठों को भी पूर्व-प्राप्त करता है, इसलिए पेज दोषों पर अवरुद्ध होने की संभावना नहीं है, लेकिन यह सुनिश्चित करने के लिए कि मैंने 300 धागे तक पहुंचने की कोशिश की है।
यह लिनक्स कर्नेल 2.6.32-27-जेनेरिक (उबंटू सर्वर x64 एलटीएस 10.04) पर चल रहा है। जीसीसी संस्करण 4.4.3 है और बूस्ट :: एएसओ संस्करण 1.40 है (दोनों स्टॉक उबंटू एलटीएस हैं)।
vmstat, iostat और top चल रहा है, मुझे लगता है कि डिस्क थ्रूपुट (टीपीएस और डेटा वॉल्यूम दोनों में)% के एकल अंकों पर है। इसी तरह, डिस्क कतार की लंबाई हमेशा धागे की संख्या से बहुत छोटी होती है, इसलिए मुझे नहीं लगता कि मैं I/O बाध्य हूं। इसके अलावा, आरएसएस चढ़ता है लेकिन फिर कुछ गीग्स (अपेक्षित के रूप में) पर स्थिर हो जाता है और vmstat कोई पेजिंग नहीं दिखाता है, इसलिए मुझे लगता है कि मैं स्मृति बाध्य नहीं हूं। सीपीयू 0-1% उपयोगकर्ता, 6-7% सिस्टम और शेष निष्क्रिय के रूप में स्थिर है। सुराग! एक पूर्ण "कोर" (हाइपर-थ्रेडिंग याद रखें) CPU का 6.25% है।
मुझे पता है कि सिस्टम पीछे गिर रहा है, क्योंकि क्लाइंट मशीन टीसीपी पर ब्लॉक करती है जब 64kb से अधिक बकाया है, और तथ्य की रिपोर्ट करें; वे सभी इस तथ्य की रिपोर्ट करते रहते हैं, और प्रणाली के माध्यम से थ्रूपुट वांछित, इरादा, और सैद्धांतिक रूप से संभव से बहुत कम है।
मेरा अनुमान है कि मैं किसी प्रकार के लॉक पर विरोध कर रहा हूं। मैं एक लुक-अप तालिका को संरक्षित करने के लिए एप्लिकेशन-स्तरीय लॉक का उपयोग करता हूं जिसे उत्परिवर्तित किया जा सकता है, इसलिए मैंने इसे निर्भरता को तोड़ने के लिए इसे 256 शीर्ष-स्तरीय ताले/तालिकाओं में शेड किया। हालांकि, यह बिल्कुल मदद नहीं कर रहा था।
सभी धागे एक, वैश्विक io_service उदाहरण के माध्यम से जाते हैं। एप्लिकेशन पर चलने वाली स्ट्रेस से पता चलता है कि यह फ्यूटेक्स कॉल से निपटने में अपना अधिकांश समय बिताता है, जो मुझे लगता है कि io_service रिएक्टर के ईवेंट-आधारित कार्यान्वयन के साथ क्या करना है।
क्या यह संभव है कि मैं रिएक्टर थ्रूपुट सीमित हूं? मैं कैसे बताऊंगा? कितना महंगा और स्केलेबल (धागे में) io_service का कार्यान्वयन है?
संपादित करें: मुझे शुरुआत में यह अन्य धागा नहीं मिला क्योंकि यह टैग का एक सेट इस्तेमाल करता था जो मेरा ओवरलैप नहीं करता था: -/यह काफी संभव है कि मेरी समस्या अत्यधिक :: लॉकिंग के कार्यान्वयन में उपयोग की जा रही है रिएक्टर। C++ Socket Server - Unable to saturate CPU देखें, हालांकि सवाल यह है कि: मैं इसे कैसे साबित कर सकता हूं? और मैं इसे कैसे ठीक कर सकता हूं?
क्या आपने एएसओ के नए संस्करणों का उपयोग करके प्रदर्शन की तुलना की है? बूस्ट 1.40 एक छोटा सा पुराना है और कुछ अच्छे सुधार एकीकृत हुए [काफी हाल ही में] (http://think-async.com/Asio/LinuxPerformanceImprovements)। –
मैं कुछ हद तक उबंटू 10.04 एलटीएस का उपयोग करने के लिए बाध्य हूं, जो 1.40 के साथ आता है। मैं शायद इसे एक और आधुनिक प्रणाली पर परीक्षण कर सकता हूं, लेकिन इसे अभी भी स्टॉक 10.04 पर तैनाती की जरूरत है। मुझे लगता है कि boost :: asio केवल हेडर है, इसलिए शायद इसे काम करने के लिए बनाया जा सकता है ... –
सैम: मैंने नवीनतम रिलीज़ बूस्ट के साथ प्रयास किया, जो कि 1.47.0 है। यह अभी भी एक ही समस्या है - प्रदर्शन एक एकल सीपीयू कोर से अधिक होने से इंकार कर देता है (हालांकि सभी कोर वास्तव में कुछ काम कर रहे हैं, बस ज्यादातर अवरुद्ध)। –