कर्नेल सॉकेट संरचना और TCP_DIAG

Question

मैं एक सॉफ्टवेयर पर काम कर रहा हूं जो रियल टाइम डेटा सर्वर (टीसीपी का उपयोग करके) से जुड़ता है और मेरे पास कुछ कनेक्शन हैं। मेरा अनुमान है कि क्लाइंट तेजी से सर्वर से आने वाले डेटा को नहीं पढ़ते हैं। इसलिए मैं अपने टीसीपी सॉकेट्स की निगरानी करना चाहूंगा। इसके लिए मुझे "ss" टूल मिला।

यह उपकरण प्रत्येक सॉकेट की स्थिति को देखने की अनुमति देता है - यहां कमांड के आउटपुट का एक उदाहरण लाइन है ss -inm 'src *:50000'

ESTAB      0      0             184.7.60.2:50000       184.92.35.104:1105
  mem:(r0,w0,f0,t0) sack rto:204 rtt:1.875/0.75 ato:40

मेरा प्रश्न है: मेमोरी भाग का क्या अर्थ है? उपकरण के स्रोत कोड को देखकर मैंने पाया कि डेटा कर्नेल संरचना ( sockसे sock.h) में आ रहा है । अधिक सटीक रूप से, यह खेतों से आता है:

r = sk->sk_rmem_alloc
w = sk->sk_wmem_queued;
f = sk->sk_forward_alloc;
t = sk->sk_wmem_alloc;

क्या किसी को पता है कि उनका क्या मतलब है? मेरे अनुमान हैं:

• rmem_alloc : इनबाउंड बफर का आकार
• wmem_alloc : आउटबाउंड बफर का आकार
• sk_forward_alloc : ???
• sk->sk_wmem_queued : ???

यहाँ मेरे बफ़र्स आकार हैं:

net.ipv4.tcp_rmem = 4096        87380   174760
net.ipv4.tcp_wmem = 4096        16384   131072
net.ipv4.tcp_mem = 786432       1048576 1572864
net.core.rmem_default = 110592
net.core.wmem_default = 110592
net.core.rmem_max = 1048576
net.core.wmem_max = 131071

Comments

आपका बफर आकार विन्यास क्या है? क्या आपको सॉकेट कनेक्शन पर संतृप्त होने वाले बफ़र्स मिलते हैं? क्या आपकी पार्टी EWOULDBLOCK पर कनेक्शन छोड़ती है?

— कार्लसन

मेरे सॉकेट का आकार काफी छोटा है, मुझे लगता है कि मैंने उनके साथ पोस्ट को अपडेट किया है। EWOULDBLOCK के लिए मैं नहीं बता सकता। मेरा ग्राहक जावा में है और यह कहना है कि यह सर्वर द्वारा काट दिया गया है। सर्वर C ++ में है और यह सिर्फ यह कहता है कि उसने बिना किसी सूचना के कनेक्शन को गिरा दिया। मेरे पास सर्वर का सोर्स कोड नहीं है इसलिए मैं इसका व्यवहार नहीं बदल सकता। ऐसा लगता है कि जब वे थोड़े से ओवरलोडेड होते हैं, तो ग्राहक डिसकनेक्ट हो जाते हैं, भले ही वह कुछ सेकंड ही चले।

— ट्विस्टर

क्या सर्वर पर बफर साइज का कॉन्फ़िगरेशन एडजस्टेबल है? क्या आप ग्राहक पर बफर आकार देख सकते हैं? क्या आपके पास क्लाइंट के स्रोत तक पहुंच है? क्या आपने बफर आकार देखने के लिए netstat -apnc चलाया है? क्या आपने कर्नेल में बफर के आकार को बढ़ाने की कोशिश की कि क्या होता है?

— कार्लसन

हां वे हैं, और पहले से ही सर्वर के अधिकतम मूल्य पर सेट हैं (मेरा मानना ​​है कि वे net.ipv4.tcp_ * गुण, अधिकार से बड़ा नहीं हो सकता?) Netstat -apnc के लिए यह मुझे बफ़र्स आकार नहीं देता है? यही कारण है कि मैं एसएस को देखा। कर्नेल के लिए मैं सर्वर पर रूट नहीं हूं, और यहां आईटी टीमें बहुत जिद्दी हैं। मुझे यह सुनिश्चित करने की आवश्यकता है कि इससे पहले कि मैं उन्हें मान बदलने के लिए कहूं ... और हां मेरे पास क्लाइंट स्रोत तक पहुंच है, और क्लाइंट पर मेरी जांच यह पुष्टि करती है कि डिस्कनेक्ट सर्वर से आता है।

— ट्विस्टर

netstat -apnc आपको लिनक्स पर भेजने और प्राप्त करने का कुल आकार देता है। यदि सर्वर बफर को अधिकतम उपलब्ध करता है और आप अभी भी संतृप्त कर रहे हैं तो शायद आपको ओएस स्तर पर उच्च बफर सेटिंग्स की आवश्यकता है

— कार्लसन

Answer 1

sk_forward_alloc आगे आवंटित स्मृति है जो वर्तमान में सॉकेट के कोटे में उपलब्ध कुल मेमोरी है।

sk_wmem_queued सॉकेट द्वारा उपयोग की जाने वाली मेमोरी की मात्रा प्रेषित कतार में कतारबद्ध बफर भेजती है और या तो अभी तक बाहर नहीं भेजी जाती है या अभी तक स्वीकार नहीं की जाती है।

आप टीसीपी / आईपी आर्किटेक्चर के अध्याय 9 में टीसीपी मेमोरी मैनेजमेंट , लिनक्स में डिजाइन और कार्यान्वयन समीर सेठ, एम। अजयकुमार वेंकटेशुलु के बारे में अधिक जान सकते हैं ।

Comments

मुझे समझ में नहीं आता है कि इस से sk_wmem_queuedभिन्न की परिभाषा sk_wmem_alloc, क्या आप इस पर थोड़ा विस्तार कर सकते हैं? (यदि आप उत्तर जानते हैं, तो इस प्रश्न का उत्तर देने के लिए स्वतंत्र महसूस करें: unix.stackexchange.com/questions/551444/… )

— थोड़ा-सा दोस्त

Answer 2

Ss का मैन पेज देखें।

<fwd_alloc>
   The  memory allocated by the socket as cache, but not used for receiving/sending packet yet. If need memory to send/receive packet, the memory in this cache will be used before allocate additional memory.

<wmem_queued>
   The memory allocated for sending packet (which has not been sent to layer 3)

Answer 3

के बारे में sk_wmem_queuedऔर sk_wmem_alloc, मैं एक ही सवाल पूछा तो मैं यहाँ जवाब की नकल करेंगे:

मैंने एरिक दुमाज़ेट को ईमेल किया, जो लिनक्स नेटवर्क स्टैक में योगदान देता है, और यहाँ उत्तर है:

sk_wmem_allocपरिवहन स्टैक के बाद कतारबद्ध skb के लिए बाइट्स की संख्या को ट्रैक करता है : qdisc layer और NIC TX रिंग बफ़र्स।

यदि आपके पास टीसीपी में 1 एमबी डेटा बैठा है, तो कतार में न लिखें, अभी तक नहीं भेजा गया है (सीडब्ल्यूडी सीमा), sk_wmem_queueलगभग 1 एमबी sk_wmem_allocहोगी , लेकिन लगभग 0 होगी

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

नेटवर्क स्टैक स्थान पैकेट को सीधे कतारबद्ध अनुशासन में रखता है या यदि कतार पूर्ण है तो ऊपरी परतों (जैसे सॉकेट बफर) पर वापस धकेल देता है

तो मूल रूप से: sk_wmem_queuesसॉकेट बफर ( sock.sk_write_queue) sk_wmem_allocद्वारा उपयोग की जाने वाली मेमोरी है जबकि क्यूडीस्क और डिवाइस कतारों में पैकेट द्वारा उपयोग की जाने वाली मेमोरी है।