🧑🏼 🤘🏼 🚠 मैं गहराई से भूमिगत जा रहा हूं, या आपको नेटवर्क एप्लिकेशन के अनुकूलन के बारे में पता होना चाहिए 👩🏻‍🔬 👶🏿 🔝

मित्रो नमस्कार!

पिछले दो लेखों ( एक , दो ) में, हम प्रौद्योगिकियों के बीच पसंद की जटिलता में डूब गए और ओस्ट्रोवोक में हमारे समाधान के लिए इष्टतम सेटिंग्स की तलाश की। आज हम किस विषय को उठाएंगे?

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

हम गुठली का उपयोग बुद्धिमानी से करते हैं

पिछले लेख में, मैंने हाप्रोसी में सीपीयू-मैप विकल्प के बारे में बात की थी। इसके साथ, हम Haproxy प्रक्रियाओं को एक दोहरे प्रोसेसर सर्वर पर एक कोर के धागे से बांधते हैं। हमने नेटवर्क कार्ड इंटरप्ट हैंडलिंग को दूसरा कोर दिया।

नीचे एक स्क्रीन है जहां आप एक समान अलगाव देख सकते हैं। बाईं ओर, कर्नेल को हाप्रोसी द्वारा user space पर कब्जा कर लिया जाता user space , और दाईं ओर kernel space में प्रसंस्करण में बाधा डालती kernel space ।

एक नेटवर्क कार्ड से बाइंडिंग में रुकावट आती है और इसका उपयोग करके स्वचालित रूप से किया जाता है

बैश स्क्रिप्ट:

 #! /bin/bash interface=${1} if [ -z "${interface}" ];then echo "no interface specified" echo "usage: ${0} eth1" exit 1 fi nproc=$(grep 'physical id' /proc/cpuinfo|sort -u|wc -l) ncpu=$(grep -c 'processor' /proc/cpuinfo) cpu_per_proc=$[ncpu / nproc] queue_threads=$[cpu_per_proc / 2] binary_map="" cpumap="" for(( i=0; i < ncpu; i++ ));do cpumap=${cpumap}1 b+='{0..1}' done binary_map=($(eval echo ${b})) ###         ###    ,      . ethtool -L ${interface} combined ${queue_threads} || true count=${ncpu} while read irq queue;do let "cpu_num=$[count-1]" let "cpu_index=$[2**cpu_num]" printf "setting ${queue} to %d (%d)\n" $((2#${binary_map[${cpu_index}]})) ${cpu_num} printf "%x\n" "$((2#${binary_map[${cpu_index}]}))" > /proc/irq/${irq}/smp_affinity [ ${interface} != ${queue} ] && count=$[count-1] [ $[ncpu - count] -gt ${queue_threads} ] && count=${ncpu} done < <(awk "/${interface}/ {if(NR > 1){ sub(\":\", \"\", \$1); print \$1,\$(NF)} }" /proc/interrupts) exit 0

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

हाप्रोसी में, हमने पहले कर्नेल के साथ शुरू होने वाली प्रक्रियाओं को कर्नेल से जोड़ा। वही पटकथा अंतरा को बांधती है, जो आखिरी से शुरू होती है। इस प्रकार, हम सर्वर प्रोसेसर को दो शिविरों में विभाजित कर सकते हैं।

रुकावट और नेटवर्किंग में गहरी जानकारी के लिए, मैं इस लेख को पढ़ने की अत्यधिक सलाह देता हूं।

हम नेटवर्क उपकरणों की क्षमताओं को प्रकट करते हैं

ऐसा होता है कि एक पल में कई महान फ्रेम नेटवर्क पर उड़ सकते हैं, और कार्ड कतार मेहमानों की ऐसी आमद के लिए तैयार नहीं हो सकती है, भले ही उसके पास ऐसा करने का अवसर हो।

नेटवर्क कार्ड बफर के बारे में बात करते हैं। अधिकतर, डिफ़ॉल्ट मान पूरे उपलब्ध बफ़र का उपयोग नहीं करते हैं। आप शक्तिशाली एथलेटिक उपयोगिता का उपयोग करके वर्तमान सेटिंग्स देख सकते हैं।

कमांड उपयोग उदाहरण:

 > ethtool -g eno1 Ring parameters for eno1: Pre-set maximums: RX: 4096 RX Mini: 0 RX Jumbo: 0 TX: 4096 Current hardware settings: RX: 256 RX Mini: 0 RX Jumbo: 0 TX: 256

अब जीवन से सब कुछ लेते हैं:

 > ethtool -G eno1 rx 4096 tx 4096 > ethtool -g eno1 Ring parameters for eno1: Pre-set maximums: RX: 4096 RX Mini: 0 RX Jumbo: 0 TX: 4096 Current hardware settings: RX: 4096 RX Mini: 0 RX Jumbo: 0 TX: 4096

अब आप यह सुनिश्चित कर सकते हैं कि कार्ड को नियंत्रित नहीं किया गया है और इसकी क्षमताओं के अधिकतम पर काम करता है।

अधिकतम लाभ के लिए न्यूनतम sysctl सेटिंग्स

सभी रंगों और आकारों में Sysctl के पास कई प्रकार के विकल्प हैं जिनकी आप कल्पना कर सकते हैं। और, एक नियम के रूप में, इंटरनेट पर लेख, अनुकूलन के मुद्दे को संबोधित करते हुए, इन मापदंडों के एक प्रभावशाली हिस्से को कवर करते हैं। मैं केवल उन लोगों पर विचार करूंगा जो हमारे मामले में बदलने के लिए वास्तव में उपयोगी थे।

net.core.netdev_max_backlog - वह कतार जहां नेटवर्क कार्ड से फ़्रेम प्राप्त होते हैं, जो तब कर्नेल द्वारा संसाधित होते हैं। तेज इंटरफेस और बड़ी मात्रा में यातायात के साथ, यह जल्दी से भर सकता है। डिफ़ॉल्ट : 1000।
हम / proc / net / softnet_stat फ़ाइल के दूसरे कॉलम को देखकर इस कतार की अधिकता का निरीक्षण कर सकते हैं।

 awk '{print $2}' /proc/net/softnet_stat

फ़ाइल में सिस्टम में प्रत्येक CPU के लिए प्रति पंक्ति netif_rx_stats की संरचना का वर्णन है।
विशेष रूप से, दूसरा कॉलम गिराए गए राज्य में पैकेट की संख्या का वर्णन करता है। यदि दूसरे कॉलम में मान समय के साथ बढ़ता है, तो यह शायद net.core.netdev_max_backlog का मूल्य बढ़ाने या सीपीयू को तेजी से डालने के लायक है।

net.core.rmem_default / net.core.rmem_max && net.core.wmem_default / net.core.wmem_max - ये पैरामीटर सॉकेट पढ़ने और लिखने वाले बफ़र्स के लिए डिफ़ॉल्ट मान / अधिकतम मान इंगित करते हैं। सॉकेट के निर्माण के समय डिफ़ॉल्ट स्तर को एप्लीकेशन स्तर पर बदला जा सकता है (वैसे, हाप्रोसी का एक पैरामीटर है जो ऐसा करता है)। हमारे पास ऐसे मामले थे जब कर्नेल ने हाप्रोक्सी की तुलना में अधिक पैकेट फेंक दिए थे, और फिर समस्याएं शुरू हो गईं। इसलिए, बात महत्वपूर्ण है।

net.ipv4.tcp_max_syn_backlog - नए कनेक्शन की सीमा के लिए जिम्मेदार है जो अभी तक स्थापित नहीं हुआ है जिसके लिए एक SYN पैकेट प्राप्त हुआ था। यदि नए कनेक्शन की एक बड़ी धारा है (उदाहरण के लिए, Connection: close से बहुत सारे HTTP अनुरोध Connection: close ), तो यह मूल्य बढ़ाने के लिए समझ में आता है ताकि आगे के पैकेट भेजने में समय बर्बाद न हो।

net.core.somaxconn - यहां हम स्थापित कनेक्शन के बारे में बात कर रहे हैं, लेकिन अभी तक आवेदन द्वारा संसाधित नहीं किया गया है। यदि सर्वर एकल-थ्रेडेड है, और दो अनुरोध उसके पास आए, तो पहला अनुरोध accept() फ़ंक्शन द्वारा संसाधित किया जाएगा, और दूसरा backlog में backlog , जिसका आकार इस पैरामीटर के लिए जिम्मेदार है।

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

की निगरानी करना। स्पष्ट और बहुत नहीं

"आपकी प्रॉक्सी धीमा क्यों हो रही है" के लिए नेत्रहीन खोज करने के लिए नहीं, यह कुछ ग्राफ़ को सेट करने और उन्हें ट्रिगर के साथ ओवरले करने के लिए उपयोगी होगा।

nf_conntrack_count सबसे स्पष्ट मीट्रिक है। इस पर, आप यह देख सकते हैं कि अब कॉनट्रैक टेबल में कितने कनेक्शन हैं। जब तालिका ओवरफ्लो हो जाती है, तो नए कनेक्शन के लिए मार्ग बंद हो जाएगा।

वर्तमान मूल्य यहां पाया जा सकता है:

 cat /proc/sys/net/netfilter/nf_conntrack_count

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

हमारे देश में, मूल्यों में वृद्धि सबसे अधिक बार आपूर्तिकर्ताओं में से एक के साथ समस्याओं को इंगित करती है, हालांकि सर्वर और नेटवर्क दोनों के प्रदर्शन के साथ समस्याएं रही हैं।

सत्यापन के लिए उदाहरण:

 netstat -s|grep 'segments retransmited'

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

मैंने इस मीट्रिक के साथ ग्राफ़ में पहाड़ों को देखा, जब हाप्रोक्सी में मैक्सकोन पैरामीटर का डिफ़ॉल्ट मान (2000) था, और यह बस नए कनेक्शन को स्वीकार नहीं करता था।

और फिर से एक उदाहरण:

 ss -lntp|awk '/LISTEN/ {print $2}'

यह टीसीपी कनेक्शन की स्थिति के टूटने के साथ एक ग्राफ होने के लिए बहुत कम नहीं होगा:

और अलग से time-wait/established , क्योंकि एक नियम के रूप में, उनके मूल्य बाकी से बहुत अलग हैं:

इन मैट्रिक्स के अलावा, कई अन्य हैं, लेकिन अधिक स्पष्ट - उदाहरण के लिए, नेटवर्क इंटरफ़ेस या सीपीयू पर लोड। उनकी पसंद आपके कार्यभार की बारीकियों पर पहले से अधिक निर्भर करेगी।

एक निष्कर्ष के बजाय

सामान्य तौर पर, यह सब - मैंने उन महत्वपूर्ण बिंदुओं का वर्णन करने की कोशिश की, जिन्हें मुझे http रिवर्स प्रॉक्सी सेट करते समय सामना करना पड़ा था। ऐसा लगता है कि कार्य मुश्किल नहीं है, लेकिन लोड में वृद्धि के साथ, गलत समय पर हमेशा पॉप अप करने वाले नुकसान की संख्या भी बढ़ जाती है। मुझे उम्मीद है कि यह लेख आपको उन कठिनाइयों से बचने में मदद करता है जो मुझे सामना करना पड़ा था।

सभी शांति

मैं गहराई से भूमिगत जा रहा हूं, या आपको नेटवर्क एप्लिकेशन के अनुकूलन के बारे में पता होना चाहिए

हम गुठली का उपयोग बुद्धिमानी से करते हैं

हम नेटवर्क उपकरणों की क्षमताओं को प्रकट करते हैं

अधिकतम लाभ के लिए न्यूनतम sysctl सेटिंग्स

की निगरानी करना। स्पष्ट और बहुत नहीं

एक निष्कर्ष के बजाय

More articles: