TCP_NODELAY सक्षम

Question

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

1) किस मामले में, और क्यों, लूपबैक पर संचार करना नेटवर्क से धीमा होगा?

2) जितनी जल्दी हो सके भेजते समय, TCP_NODELAY को टॉगल करने से नेटवर्क पर अधिक लूपबैक पर अधिकतम थ्रूपुट पर इतना असर पड़ता है?

3) हम खराब प्रदर्शन के लिए संभावित स्पष्टीकरण के रूप में टीसीपी भीड़ नियंत्रण का पता लगाने और विश्लेषण कैसे कर सकते हैं?

4) क्या किसी के पास इस घटना के कारण के रूप में कोई अन्य सिद्धांत है? यदि हां, तो सिद्धांत साबित करने के लिए कोई तरीका?

• मैं केवल के साथ छोटे इस मुद्दे देखें:

   
  Transport  Message Size (bytes) TCP NoDelay Send Buffer (bytes) Sender Host Receiver Host Throughput (bytes/sec) Message Rate (msgs/sec) 
  TCP   128     On   16777216    HostA   HostB   118085994    922546 
  TCP   128     Off   16777216    HostA   HostB   118072006    922437 
  TCP   128     On    4096    HostA   HostB   11097417     86698 
  TCP   128     Off    4096    HostA   HostB   62441935    487827 
  TCP   128     On   16777216    HostA   HostA   20606417    160987 
  TCP   128     Off   16777216    HostA   HostA   239580949    1871726 
  TCP   128     On    4096    HostA   HostA   18053364    141041 
  TCP   128     Off    4096    HostA   HostA   214148304    1673033 
  UnixStream 128     -    16777216    HostA   HostA   89215454    696995 
  UnixDatagram 128     -    16777216    HostA   HostA   41275468    322464 
  NamedPipe  128     -    -      HostA   HostA   73488749    574130 
  

  यहाँ उपयोगी जानकारी के कुछ और टुकड़े कर रहे हैं:

  यहाँ C++ एप्लिकेशन बात करने के लिए कुछ नमूना एक साधारण बिंदु द्वारा उत्पन्न डेटा है संदेश

• होस्टा और होस्टबी दोनों में एक ही हार्डवेयर किट (ज़ीऑन X5550@2.67GHz, 32 कोर कुल/128 गीग मेम/1 गीग एनआईसीएस)
• ओएस RHEL 5.4 कर्नेल 2.6.18-164.2.1.el5)

आप व्यक्तिगत रूप से धन्यवाद

Answer 1

1 या 2) मुझे यकीन है कि नहीं कर रहा हूँ तुम क्यों बिल्कुल लूपबैक उपयोग करने के लिए परेशान कर रहे हैं, मैं है यह नहीं पता कि यह एक वास्तविक इंटरफ़ेस की नकल करेगा और यह कितना वैध होगा। मुझे पता है कि माइक्रोसॉफ्ट लूपबैक इंटरफ़ेस के लिए NAGLE को अक्षम करता है (यदि आप परवाह करते हैं)। this link पर एक नज़र डालें, इसके बारे में एक चर्चा है।

3) मैं दोनों मामलों में पहले कुछ पैकेट को बारीकी से देखता हूं और देखता हूं कि आपको पहले पांच पैकेट में गंभीर देरी हो रही है या नहीं। देखें here

Answer 2

1) किस मामले में, और क्यों, लूपबैक पर संचार करना नेटवर्क से धीमा हो जाएगा?

लूपबैक दोनों tx एक ही मशीन पर + rx के लिए पैकेट सेटअप + टीसीपी chksum गणना डालता है, तो यह 2x के रूप में ज्यादा प्रसंस्करण करने की जरूरत है, जबकि 2 मशीनों के साथ आप उन दोनों के बीच विभाजित tx/rx। इसका लूपबैक पर नकारात्मक प्रभाव हो सकता है।

2) जब यथासंभव शीघ्र भेजने, क्यों TCP_NODELAY इतना नेटवर्क पर से लूपबैक से अधिक अधिकतम प्रवाह पर असर के अधिक है टॉगल करता है?

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

3) हम खराब प्रदर्शन के लिए संभावित स्पष्टीकरण के रूप में टीसीपी भीड़ नियंत्रण का पता लगाने और विश्लेषण कैसे कर सकते हैं?

कंजेशन नियंत्रण केवल पैकेट नुकसान होने पर ही चलता है। क्या आप पैकेट नुकसान देख रहे हैं? अन्यथा, आप शायद टीसीपी विंडो आकार बनाम नेटवर्क विलंबता कारकों पर सीमाएं मार रहे हैं।

4) क्या किसी के पास इस घटना के कारण के रूप में कोई अन्य सिद्धांत है? यदि हां, तो सिद्धांत साबित करने के लिए कोई तरीका?

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

एक अंतिम ध्यान दें: छोटे संदेशों जैसे विभिन्न कारणों से, के लिए अपने नेटवर्क पर एक बहुत बड़ा प्रदर्शन हिट बनाने के लिए:

(मैक + आईपी + टीसीपी हेडर के लिए)

• वहाँ एक पैकेट भूमि के ऊपर प्रति तय हो गई है, और पेलोड जितना छोटा होगा, उतना अधिक ओवरहेड होगा।
• कई एनआईसी सीमाएं बकाया पैकेट के # के सापेक्ष हैं, जिसका मतलब है कि आप छोटे पैकेट का उपयोग करते समय एनआईसी बाधाओं को बहुत कम डेटा के साथ दबाएंगे।
• नेटवर्क स्वयं प्रति-पैकेट ओवरहेड के रूप में है, इसलिए नेटवर्क के माध्यम से आप अधिकतम मात्रा में डेटा पंप कर सकते हैं, फिर से पैकेट के आकार पर निर्भर है।

Answer 3

वही समस्या है जिसका सामना मैंने किया था। उसी RHEL6 मशीन में चल रहे दो घटकों के बीच 2 एमबी डेटा स्थानांतरित करते समय, इसे पूरा करने में 7 सेकंड लग गए। जब डेटा का आकार बड़ा होता है, तो समय स्वीकार्य नहीं होता है। 10 एमबी डेटा स्थानांतरित करने में 1 मिनट लग गए।

फिर मैंने TCP_NODELAY अक्षम के साथ प्रयास किया है। इसने समस्या को हल किया

ऐसा तब नहीं होता जब दोनों घटक दो अलग-अलग मशीनों में हों।