क्या है "टीसीपी-बैकलॉग" redis.conf में

Question

मैं redis.conf में tcp-backlog से उलझन में हूँ:

# TCP listen() backlog. 
# 
# In high requests-per-second environments you need an high backlog in order 
# to avoid slow clients connections issues. Note that the Linux kernel 
# will silently truncate it to the value of /proc/sys/net/core/somaxconn so 
# make sure to raise both the value of somaxconn and tcp_max_syn_backlog 
# in order to get the desired effect. 
tcp-backlog 511 

tcp-backlog "पूरा कनेक्शन कतार" (तीन तरह हाथ मिलाना के आकार पूरा हो गया है, क्या है here वर्णित) या "अपूर्ण कनेक्शन कतार"?

यदि इसका मतलब है "पूर्ण कनेक्शन कतार" तो मुझे tcp_max_syn_backlog क्यों बढ़ाया जाना चाहिए जो अपूर्ण कनेक्शन कतार के आकार को सीमित करता है?

Answer 1

क्या टीसीपी बैकलॉग "पूर्ण कनेक्शन कतार" (तीन-तरफा हैंडशेक पूर्ण, यहां वर्णित है) या "अपूर्ण कनेक्शन कतार" का आकार है?

tcp-backlogपूरा कनेक्शन कतार का आकार है। वास्तव में, रेडिस इस कॉन्फ़िगरेशन को listen(int s, int backlog) कॉल के दूसरे पैरामीटर के रूप में पास करता है।

@ गुआंग्सेंगज़ुओ पहले से ही इस प्रश्न के लिए एक अच्छा जवाब था। तो मैं दूसरे पर ध्यान केंद्रित करूंगा।

यदि इसका अर्थ है "पूर्ण कनेक्शन कतार" तो मुझे tcp_max_syn_backlog क्यों बढ़ाया जाना चाहिए जो अपूर्ण कनेक्शन कतार के आकार को सीमित करता है? दस्तावेज़ से

उद्धरण आपका उल्लेख किया:

कार्यान्वयन दो कतारों, एक SYN कतार (या अधूरा कनेक्शन कतार) और एक को स्वीकार कतार (या पूरा कनेक्शन कतार) का उपयोग करता है। राज्य एसईएन रिसीव में कनेक्शन एसईएन कतार में जोड़े जाते हैं और बाद में जब उनकी स्थिति स्थापित करने के लिए बदलती है तो स्वीकार की गई कतार में स्थानांतरित हो जाता है, यानी जब 3-तरफा हैंडशेक में एसीके पैकेट प्राप्त होता है। जैसा कि नाम का तात्पर्य है, स्वीकृति कॉल को स्वीकार कतार से कनेक्शन का उपभोग करने के लिए लागू किया जाता है। इस मामले में, श्रवण syscall का बैकलॉग तर्क स्वीकार कतार के आकार को निर्धारित करता है।

हम देख सकते हैं कि complete connection queue में आइटम incomplete connection queue से ले जाया जाता है।

आप एक बड़े somaxconn एक छोटे से tcp_max_syn_backlog साथ है, तो आपके पास पर्याप्त आइटम नहीं हो सकता complete connection queue में स्थानांतरित करने की है, और complete connection queue कभी नहीं पूरा हो सकता है। पहले से ही स्थानांतरित होने का मौका मिलने से पहले कई अनुरोध पहले कतार से पहले से ही हटा दिए जा सकते हैं।

तो केवल somaxconn का मान बढ़ाएं काम नहीं कर सकता है। आपको दोनों को उठाना होगा।

Answer 2

टीसीपी-बैकलॉग स्वीकार कतार या पूर्ण कनेक्शन कतार का आकार है।

डॉक्स आप उल्लेख किया है ने कहा:

लिनक्स पर, चीजों के रूप में सुनने को syscall मैन ऑफ द पेज में उल्लेख किया है, अलग-अलग हैं:

TCP सॉकेट पर बैकलॉग तर्क के व्यवहार लिनक्स 2.2 के साथ बदल गया। अब यह पूरी तरह से स्थापित सॉकेट के लिए कतार लंबाई निर्दिष्ट करता है, अपूर्ण कनेक्शन अनुरोधों की संख्या के बजाय स्वीकार किए जाने की प्रतीक्षा कर रहा है। अपूर्ण सॉकेट के लिए कतार की अधिकतम लंबाई/proc/sys/net/ipv4/tcp_max_syn_backlog का उपयोग करके सेट की जा सकती है।

इसका मतलब यह है कि मौजूदा लिनक्स संस्करणों दो अलग-अलग कतारों के साथ दूसरे विकल्प का उपयोग: एक आकार एक प्रणाली विस्तृत सेटिंग द्वारा निर्दिष्ट के साथ एक SYN कतार और एक आकार आवेदन द्वारा निर्दिष्ट के साथ एक को स्वीकार कतार।

Redis सर्वर का उपयोग टीसीपी-बैकलॉग की config सुनने के साथ स्वीकार कतार के आकार निर्दिष्ट करने के लिए()। और SYN कतार आकार लिनक्स के व्यवस्थापक द्वारा निर्धारित किया जाता है।

यदि इसका अर्थ है "पूर्ण कनेक्शन कतार", तो मुझे tcp_max_syn_backlog क्यों बढ़ाया जाना चाहिए जो अपूर्ण कनेक्शन कतार के आकार को सीमित करता है?

tcp_max_syn_backlog को बढ़ाने का लक्ष्य धीमी क्लाइंट कनेक्शन समस्याओं से बचें। यदि कुछ धीमे ग्राहक हैं जो रेडिस सर्वर के साथ 3-तरफा हैंडशेक कर रहे हैं, और ये क्लाइंट प्रतिक्रिया पढ़ने और अनुरोध भेजने में धीमे हैं, तो वे लंबे समय तक रेडिस सर्वर की SYN कतार ले लेंगे क्योंकि वे धीमे हैं।

और कुछ मामलों में, इन अक्षम ग्राहकों के कारण SYN-queue भरा जाएगा। यदि SYN कतार भर जाती है, तो रेडिस सर्वर नए क्लाइंट को स्वीकार नहीं कर सकता है। तो आपको इससे निपटने के लिए tcp_max_syn_backlog को उठाना चाहिए।

Answer 3

कल, मैं Redis इन एक्शन में अध्याय 6 पढ़ जहां यहोशू कार्लटन लिखते हैं कि "Redis की खामियों में से एक प्रकाशित करें और सदस्यता लें मॉडल, है कि ग्राहक को हर समय कनेक्ट होना आवश्यक है संदेश प्राप्त करने के हैं डिस्कनेक्शन कर सकते हैं क्लाइंट को संदेश खोने का कारण बनता है, और रेडिस के पुराने संस्करण अनुपयोगी, दुर्घटनाग्रस्त हो सकते हैं, या पर धीमा ग्राहक हो सकता है। "

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

Could we set a high tcp_max_syn_backlog in redis.conf to prevent either of 

यहोशू कार्लसन के एकल प्राप्तकर्ता संदेश, और प्रति सेकंड 20,000 गए संदेशों के एक लोड जहां प्रत्येक संदेश 20 बाइट्स के तहत डिस्कनेक्ट करने से कई -recipient मैसेजिंग तरीकों?