ट्यूनिंग लिनक्स आईपी रूटिंग पैरामीटर - secret_interval और tcp_mem

Question

आज हमारे HAProxy VMs में से एक के साथ हमारे पास थोड़ी विफलता थी। जब हमने इसे खोदा, तो हमने पाया:

26 जनवरी 07:41:45 haproxy2 कर्नेल: [226818.070059] __ratelimit: 10 कॉलबैक दमन
26 जनवरी 07:41:45 haproxy2 कर्नेल: [226818.070064] सॉकेट मेमोरी से बाहर
26 जनवरी 07:41:47 haproxy2 कर्नेल: [226819.560048] सॉकेट मेमोरी से बाहर
26 जनवरी 07:41:49 haproxy2 कर्नेल: [226822.030044] सॉकेट मेमोरी से बाहर

इस लिंक के अनुसार , जाहिरा तौर पर कम डिफ़ॉल्ट सेटिंग्स के साथ क्या करना है net.ipv4.tcp_mem। इसलिए हमने उन्हें उनके डिफॉल्ट्स से 4 गुना बढ़ा दिया (यह उबंटू सर्वर है, निश्चित नहीं कि लिनक्स फ्लेवर मायने रखता है):

वर्तमान मान हैं: 45984 61312 91968
नए मूल्य हैं: 183936 245248 367872

उसके बाद, हमें एक विचित्र त्रुटि संदेश दिखाई देने लगा:

26 जनवरी 08:18:49 haproxy1 कर्नेल: [2291.579726] रूट हैश श्रृंखला बहुत लंबी है!
26 जनवरी 08:18:49 haproxy1 कर्नेल: [2291.579732] अपने secret_interval को समायोजित करें!

Shh .. यह एक रहस्य है !!

यह जाहिरा तौर /proc/sys/net/ipv4/route/secret_intervalपर 600 के लिए चूक और रूट कैश के आवधिक नियंत्रण के साथ करना है

secret_intervalगिरी कितनी बार दूर सभी मार्ग हैश प्रविष्टियों कैसे नए / पुराने वे कर रहे हैं की परवाह किए बिना उड़ाने की निर्देश देता है। हमारे परिवेश में यह आमतौर पर खराब है। हर बार कैश क्लियर होने पर सीपीयू हजारों प्रविष्टियां प्रति सेकंड के पुनर्निर्माण में व्यस्त होगी। हालाँकि हम इसे खाड़ी में मेमोरी लीक रखने के लिए दिन में एक बार चलाने के लिए सेट करते हैं (हालांकि हमारे पास कभी नहीं था)।

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

कुछ जाँच के बाद, हमने पाया /proc/sys/net/ipv4/route/gc_elasticityकि मार्ग तालिका आकार को जाँच में रखने के लिए एक बेहतर विकल्प है:

gc_elasticityमार्ग की हैश प्रविष्टियों को समाप्त करने से पहले कर्नेल को स्वीकार करने के लिए औसत बाल्टी की गहराई के रूप में सबसे अच्छा वर्णित किया जा सकता है। यह सक्रिय मार्गों की ऊपरी सीमा को बनाए रखने में मदद करेगा।

हमने रूट कैश की आशाओं में लोच को 8 से 4 तक समायोजित किया, जिससे खुद को अधिक आक्रामक रूप से पेश किया। secret_intervalहमारे लिए सही नहीं लगता है। लेकिन वहाँ सेटिंग्स का एक गुच्छा रहे हैं और यह स्पष्ट नहीं है जो वास्तव में यहाँ जाने का सही तरीका है।

• / proc / sys / net / ipv4 / मार्ग / gc_elasticity (8)
• / proc / sys / net / ipv4 / मार्ग / gc_interval (60)
• / proc / sys / net / ipv4 / मार्ग / gc_min_interval (0)
• / proc / sys / net / ipv4 / मार्ग / gc_timeout (300)
• / proc / sys / net / ipv4 / मार्ग / secret_interval (600)
• / proc / sys / net / ipv4 / मार्ग / gc_thresh (?)
• rhash_entries (कर्नेल पैरामीटर, डिफ़ॉल्ट अज्ञात?)

हम लिनक्स रूटिंग को बदतर नहीं बनाना चाहते हैं , इसलिए हम इनमें से कुछ सेटिंग्स के साथ गड़बड़ करने से डरते हैं।

क्या कोई सलाह दे सकता है कि उच्च यातायात HAProxy उदाहरण के लिए कौन से रूटिंग पैरामीटर सर्वोत्तम हैं?

Answer 1

मैंने कभी इस मुद्दे का सामना नहीं किया। हालाँकि, आपको इसकी गहराई कम करने के लिए अपनी हैश टेबल की चौड़ाई बढ़ानी चाहिए। "Dmesg" का उपयोग करके, आप देखेंगे कि वर्तमान में आपके पास कितनी प्रविष्टियाँ हैं:

$ dmesg | grep '^IP route'
IP route cache hash table entries: 32768 (order: 5, 131072 bytes)

आप कर्नेल बूट कमांड लाइन पैरामीटर के साथ इस मान को बदल सकते हैं rhash_entries। पहले इसे हाथ से आज़माएँ फिर इसे अपने lilo.confया में जोड़ें grub.conf।

उदाहरण के लिए: kernel vmlinux rhash_entries=131072

यह संभव है कि आपके पास एक बहुत ही सीमित हैश तालिका हो क्योंकि आपने अपने HAProxy VM को छोटी मेमोरी सौंपी है (मार्ग हैश का आकार कुल रैम के आधार पर समायोजित किया गया है)।

के संबंध में tcp_mem, सावधान रहें। आपकी प्रारंभिक सेटिंग मुझे यह बताती है कि आप 1 जीबी रैम के साथ चल रहे थे, जिनमें से 1/3 को टीसीपी सॉकेट के लिए आवंटित किया जा सकता है। अब आपने टीसीपी सॉकेट्स को 367872 * 4096 बाइट्स = 1.5 जीबी रैम आवंटित किया है। आपको बहुत ध्यान रखना चाहिए कि मेमोरी से बाहर न निकलें। अंगूठे का एक नियम मेमोरी के 1/3 को HAProxy और दूसरी 1/3 को TCP स्टैक और अंतिम 1/3 को सिस्टम के बाकी हिस्सों में आवंटित करना है।

मुझे संदेह है कि आपका "सॉकेट मेमोरी से बाहर" संदेश डिफ़ॉल्ट सेटिंग्स से tcp_rmemऔर में आता है tcp_wmem। डिफ़ॉल्ट रूप से आपके पास प्रत्येक सॉकेट के लिए आउटपुट पर 64 kB और इनपुट पर 87 kB है। इसका मतलब है एक समीपस्थ कनेक्शन के लिए कुल 300 kB, सिर्फ सॉकेट बफ़र्स के लिए। HAProxy के लिए उस 16 या 32 kB में जोड़ें, और आप देखते हैं कि 1 जीबी रैम के साथ आप केवल 3000 कनेक्शन का समर्थन करेंगे।

( tcp_rmemऔर tcp_wmemमध्य परम) की डिफ़ॉल्ट सेटिंग्स को बदलकर , आप मेमोरी पर बहुत कम प्राप्त कर सकते हैं। मुझे राइट्स के लिए अच्छे परिणाम मिलते हैं जैसे कि लिखने वाले बफर के लिए 4096, और tcp_rmem(5 या 11 टीसीपी सेगमेंट) में 7300 या 16060 । आप पुनः आरंभ किए बिना उन सेटिंग्स को बदल सकते हैं, हालांकि वे केवल नए कनेक्शन पर लागू होंगे।

यदि आप अपने sysctls को बहुत ज्यादा नहीं छूना पसंद करते हैं , तो नवीनतम HAProxy, 1.4-dev8, आपको वैश्विक कॉन्फ़िगरेशन और प्रति पक्ष (क्लाइंट या सर्वर) से उन मापदंडों को मोड़ने की अनुमति देता है।

मुझे उम्मीद है कि यह मदद करता है!

Answer 2

Out of socket memory errorअक्सर भ्रामक है। अधिकांश समय, इंटरनेट फेसिंग सर्वर पर, यह मेमोरी से बाहर चलने से संबंधित किसी भी समस्या का संकेत नहीं देता है। जैसा कि मैंने एक ब्लॉग पोस्ट में कहीं अधिक विवरण में बताया है , सबसे सामान्य कारण अनाथ सॉकेट्स की संख्या है। एक अनाथ सॉकेट एक सॉकेट है जो फ़ाइल डिस्क्रिप्टर से जुड़ा नहीं है। कुछ परिस्थितियों में, कर्नेल Out of socket memory errorआपको 2x या 4x की सीमा से दूर होने के बावजूद भी जारी करेगा /proc/sys/net/ipv4/tcp_max_orphans। यह इंटरनेट-फेसिंग सेवाओं में अक्सर होता है और पूरी तरह से सामान्य है। इस मामले में कार्रवाई का सही तरीका यह है कि tcp_max_orphansआप अपने चरम ट्रैफ़िक के साथ सामान्य रूप से देखने वाले अनाथों की संख्या कम से कम 4x करें।

किसी भी सलाह है कि ट्यूनिंग की सिफारिश की बात नहीं है tcp_memया tcp_rmemया tcp_wmemजब तक आप वास्तव में पता है कि तुम क्या कर रहे हैं। ये सलाह देने वाले आमतौर पर नहीं करते हैं। उनका वूडू आपके पर्यावरण के लिए अक्सर गलत या अनुचित होता है और इससे आपकी समस्या का समाधान नहीं होगा। यह भी बदतर बना सकता है।

Comments

जब ऐसा होता है, संदेश dmesg में अलग-अलग होता है, तो आप "बहुत सारे अनाथ सॉकेट्स" देखते हैं। हालाँकि, मैं आपसे सहमत हूँ कि अनाथों में स्मृति की भारी मात्रा हो सकती है।

— विली तरारेउ

जब आप संख्या से अधिक /proc/sys/net/ipv4/tcp_max_orphansहो जाएंगे तो आपको एक अलग त्रुटि का अनुभव होगा। उदाहरण के लिए पूरे स्टैक एक्सचेंज स्टैक /proc/sys/net/ipv4/tcp_max_orphansमें 65536 और /proc/net/sockstatटीसीपी में परिणाम हैं: 2996 अनाथ 171 जुड़वां 15972 2998 मेम 1621 आवंटित - एक अंतर जिसे अनदेखा नहीं किया जा सकता है।

— ज्योफ Dalgas

Answer 3

हम इनमें से कुछ मापदंडों को नियमित रूप से ट्यून करते हैं। उच्च थ्रूपुट, कम विलंबता ट्रेडिंग प्लेटफॉर्म के लिए हमारा मानक है:

net.ipv4.tcp_rmem = 4096 16777216 33554432
net.ipv4.tcp_wmem = 4096 16777216 33554432
net.ipv4.tcp_mem = 4096 16777216 33554432
net.core.rmem_default = 16777216
net.core.wmem_default = 16777216
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.netdev_max_backlog = 30000
net.core.netdev_max_backlog = 30000

Comments

विली के गणित के अनुसार आपका मानक मेमोरी प्रेशर # (मध्य संख्या) 68 GB है !? टाइम्स तीन (remem, wemem, मेम) ??

— जेफ एटवुड

ये ट्यून गलत हैं और बहुत बार बेंच वातावरण में पाए जाते हैं फिर नेत्रहीन कॉपी-पेस्ट किया जाता है। उन्हें केवल कुछ समवर्ती सत्रों के साथ कोई समस्या नहीं होगी, लेकिन 100 टीसीपी सॉकेट के साथ, आप 3.2 जीबी रैम आवंटित करेंगे। जब तक विलंबता कम होती है, आप कुछ भी संदिग्ध नहीं देखेंगे। आपको आउटपुट बफ़र्स को भरने, या किसी स्थानीय कार्य को फ्रीज़ करने और इनपुट बफर फिल देखने के लिए स्थानांतरण के दौरान एक दूरस्थ मशीन को अनप्लग करना होगा। यह पागल है ...

— विली तरारेयू

जेफ, यह तीन बार नहीं है। tcp_mem पृष्ठों में है और वैश्विक आकार को परिभाषित करता है। tcp_rmem और tcp_wmem बाइट्स में हैं और प्रति-सॉकेट आकार को परिभाषित करते हैं।

— विली तरारेउ

उन ट्यूनबल्स गलत दिखते हैं, छोटे डेटा वाले समवर्ती सर्वरों के लिए जो आप सॉकेट बफ़र्स को आरक्षित नहीं करना चाहते हैं और tcp_mem r / wmem से पूरी तरह से अलग है, समान संख्याओं का उपयोग करने से वास्तव में कोई मतलब नहीं है, (एक बायर्स प्रति कनेक्शन दूसरे को जोड़ता है) प्रति सिस्टम पेज)

— eckes