tcpdump udp प्रदर्शन बढ़ाता है

13

मैं निम्नलिखित सेटअप के प्रदर्शन को निर्धारित करने के लिए लोड परीक्षणों का एक सेट चला रहा हूं:

Node.js test suite (client) --> StatsD (server) --> Graphite (server)

संक्षेप में, नोड.जेएस परीक्षण सूट एक एक्सट्रास उदाहरण के लिए हर सेकंड में मीट्रिक की एक निर्धारित राशि भेजता है जो दूसरे सर्वर पर स्थित है। इसके बाद StatsD बारी-बारी से हर सेकेंड मैट्रिक्स को उसी सर्वर पर स्थित ग्रेफाइट इंस्टेंस पर फ्लश करता है। मैं तब देखता हूं कि परीक्षण सूट द्वारा वास्तव में कितने मेट्रिक्स भेजे गए थे और ग्रेफाइट द्वारा कितने प्राप्त किए गए थे जो टेस्ट सूट और ग्रेफाइट के बीच पैकेट नुकसान का निर्धारण करते हैं।

हालाँकि मैंने देखा कि मुझे कभी-कभी बहुत बड़े पैकेट ड्रॉप रेट (ध्यान दें कि इसे यूडीपी प्रोटोकॉल के साथ भेजा जा रहा है), 20-50% से लेकर। इसलिए जब मैंने यह देखना शुरू किया कि इन पैकेटों को कहां गिराया जा रहा है, यह देखते हुए कि यह StatsD के साथ कुछ प्रदर्शन का मुद्दा हो सकता है। इसलिए मैंने सिस्टम के हर हिस्से में मेट्रिक्स को लॉग करना शुरू कर दिया, ताकि यह पता चल सके कि यह ड्रॉप कहां से आई। और यह वह जगह है जहां चीजें अजीब होती हैं।

मैं कैप्चर फ़ाइल बनाने के लिए tcpdump का उपयोग कर रहा हूं, जिसे मैं परीक्षण चलाने के बाद निरीक्षण करता हूं। लेकिन जब भी मैं tcpdump के साथ परीक्षण चलाता हूं, तो पैकेट का नुकसान लगभग न के बराबर होता है! ऐसा लग रहा है कि tcpdump किसी तरह मेरे परीक्षणों के प्रदर्शन को बढ़ा रहा है और मैं यह पता नहीं लगा सकता कि यह क्यों और कैसे करता है। मैं सर्वर और क्लाइंट दोनों पर tcpdump संदेशों को लॉग करने के लिए निम्न कमांड चला रहा हूं:

tcpdump -i any -n port 8125 -w test.cap

एक विशेष परीक्षण के मामले में मैं 40000 मेट्रिक्स / एस भेज रहा हूं। Tcpdump को चलाने के दौरान परीक्षण में लगभग 4% का पैकेट नुकसान होता है, जबकि बिना पैकेट के लगभग 20% का नुकसान होता है

दोनों प्रणालियां निम्नलिखित सेटअप के साथ एक्सएमएन वीएम के रूप में चल रही हैं:

Intel Xeon E5-2630 v2 @ 2.60GHz
2 जीबी रैम
उबंटू 14.04 x86_64

संभावित कारणों के लिए पहले से ही जाँच की गई चीज़ें:

यूडीपी बफर बढ़ाने / भेजने का आकार।
सीपीयू लोड परीक्षण को प्रभावित करता है। (अधिकतम लोड 40-50%, दोनों क्लाइंट और सर्वर साइड)
'किसी' के बजाय विशिष्ट इंटरफेस पर tcpdump चलाना।
चल मोड को निष्क्रिय करने के लिए '-p' के साथ रनिंग tcpdump।
केवल सर्वर पर tcpdump चल रहा है। इसके परिणामस्वरूप पैकेट में 20% की हानि हुई और यह परीक्षणों को प्रभावित नहीं करता है।
केवल क्लाइंट पर tcpdump चल रहा है। इससे प्रदर्शन में वृद्धि हुई।
बढ़ रही netdev_max_backlog और netdev_budget से 2 ^ 32-1। इससे कोई फर्क नहीं पड़ा।
प्रत्‍येक मोड पर प्रत्‍येक सेटिंग (सर्वर ऑन और क्‍लाइंट ऑफ, सर्वर ऑफ और क्लाइंट ऑन, दोनों ऑफ) दोनों पर हर संभव सेटिंग की कोशिश की। इससे कोई फर्क नहीं पड़ा।

— रूबेन होम्स
स्रोत

3

एक चीज जो डिफ़ॉल्ट रूप से tcpdump करती है, वह आपके नेटवर्क इंटरफ़ेस को प्रोमिसस मोड में डाल देती है। आप यह -pकरने के लिए कि क्या यह एक फर्क पड़ता है देखने के लिए छोड़ विकल्प पारित करना चाहते हो सकता है ।

— Zoredache

तो आप क्लाइंट और सर्वर दोनों पर tcpdump चला रहे हैं, और पैकेट हानि दर गिरता जा रहा है? यदि आप इसे केवल क्लाइंट पर चलाते हैं, और यदि आप इसे केवल सर्वर पर चलाते हैं, तो क्या होता है? (और, हाँ, यह भी अनेक मोड को बंद करने के बजाय "किसी भी" डिवाइस से परीक्षण के लिए इस्तेमाल किया, देखने के लिए कि विशिष्ट नेटवर्क इंटरफेस पर कब्जा करने की कोशिश की कोशिश करता है और शायद कि एक फर्क पड़ता है।)

आपकी टिप्पणियों के लिए आभार। मैंने आपकी दोनों सिफारिशों को आजमाया और अपने प्रश्न को प्रतिबिंबित करने के लिए संपादित किया कि मैंने क्या प्रयास किया, लेकिन इससे समस्या प्रभावित नहीं हुई।

— रूबेन होम्स

क्या दोनों मशीनों पर नीच को मोड में लगाने से tcpdump चलाने के समान प्रभाव पड़ता है? eth0 पर उचित मोड को ifconfig eth0 promiscसक्षम और ifconfig eth0 -promiscअक्षम करता है। यदि यह अंतर करता है, तो दोनों मशीनों पर प्रोमिस के 4 संभावित संयोजनों की तुलना करके देखें। यह समस्याओं के स्रोत को इंगित करने में मदद कर सकता है।

— फॉक्स

@ फॉक्स उत्तर के लिए धन्यवाद! मैंने सभी निक के लिए सभी संभव संयोजनों की कोशिश की, लेकिन परिणामों में कोई अंतर नहीं है। मैंने इसे प्रतिबिंबित करने के लिए अपना प्रश्न अपडेट किया।

— रूबेन होम्स

10

जब tcpdump चल रहा है, तो यह आने वाले फ्रेम में पढ़ने में काफी शीघ्र होगा। मेरी परिकल्पना यह है कि एनआईसी के पैकेट रिंग बफर सेटिंग्स छोटे आकार पर थोड़ी हो सकती हैं; जब tcpdump चल रहा है तो यह अधिक समय पर खाली हो रहा है।

यदि आप Red Hat ग्राहक हैं, तो यह सपोर्ट लेख पैकेट रिसेप्शन का बहुत उपयोगी अवलोकन है । इसमें कुछ चीजें हैं जो मुझे नहीं लगता कि आपने अभी तक माना है।

इस बात पर विचार करें कि आपका सिस्टम IRQ से कैसे निपट रहा है; नेटवर्क इंटरफेस के 'देव_वेट' को बढ़ाने पर विचार करें (एनआईसी से उपयोगकर्ता-अंतरिक्ष के लिए और अधिक पैकेट पढ़ें); देखो कि आवेदन कितनी बार सॉकेट को पढ़ता है (क्या यह एक समर्पित थ्रेड का उपयोग कर सकता है, क्या स्केलेबिलिटी के बारे में ज्ञात समस्याएं / वर्कअराउंड हैं)।

एनआईसी फ्रेम बफर बढ़ाएं ( ethtoolकमांड का उपयोग करें - --set-ringआदि तर्कों को देखें)।

'अगल-बगल स्केलिंग' देखें और कम से कम उपयोग करें कि ट्रैफ़िक में पढ़ने के लिए कई धागे मिलते हैं।

मुझे आश्चर्य है कि अगर tcpdump कुछ अच्छा कर रहा है जैसे कि पैकेट रिंग बफ़र्स के लिए कर्नेल समर्थन का उपयोग करना । यह आपके द्वारा देखे जा रहे व्यवहार को समझाने में मदद करेगा।

— कैमरन केर
स्रोत

चूंकि यह एक Xen वातावरण है, आपको शायद (कम से कम कुछ) ऐसा करना चाहिए जो कि Xen होस्ट पर हो।

— कैमरन केर

यह कुछ ऐसा है जो मैंने पहले नहीं सोचा था, बहुत दिलचस्प चीजें, धन्यवाद! मैं इसे एक बार कोशिश करूंगा कि मैं एक्सएन होस्ट तक पहुंच पाऊं और आपको बता दूं कि कैसे जाता है।

— रूबेन होम्स

2

आप किस पावर गवर्नर का उपयोग कर रहे हैं? मैंने "ondemand" या "रूढ़िवादी" गवर्नर के साथ समान व्यवहार देखा है।

"प्रदर्शन" राज्यपाल का उपयोग करने की कोशिश करें और सर्वर BIOS में किसी भी शक्तियां सुविधाओं को अक्षम करें।

क्या यह कुछ बदलता है?

— shodanshok
स्रोत

मुझे यह पता लगाने में परेशानी हो रही है कि मैं किस पावर गवर्नर का उपयोग कर रहा हूं। मैंने दौड़ने की कोशिश की cpufreq-infoलेकिन एक संदेश मिला no or unknown cpufreq driver is active on this CPU। cpupower frequency-infoइसका उपयोग करते समय भी रिटर्न no or unknown cpufreq driver is active on this CPU। हालांकि मैं इस समय इसकी पुष्टि नहीं कर सकता, VM निर्माता की वेबसाइट मुझे विश्वास दिलाती है कि यह "प्रदर्शन" मोड पर चल रहा है क्योंकि मेरे पास एक इंटेल सीपीयू है ..

— रुबेन होम्स

क्या आप निम्न कमांड का आउटपुट दिखा सकते हैं? 1) cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor2) cat /proc/cpuinfo3)lsmod | grep cpu

— शोडांशोक

यहाँ आप जाते हैं

— रूबेन होम्स

1

दूसरा तरीका ip_conntarckमॉड्यूल है, क्या आप सुनिश्चित हैं कि आपका लिनक्स-बॉक्स नए कनेक्शन को स्वीकार कर सकता है? के माध्यम से परीक्षण:

root@debian:/home/mohsen# sysctl net.ipv4.netfilter.ip_conntrack_max
net.ipv4.netfilter.ip_conntrack_max = 65536
root@debian:/home/mohsen# sysctl  net.ipv4.netfilter.ip_conntrack_count
net.ipv4.netfilter.ip_conntrack_count = 29

आपको परीक्षण करना होगा

net.ipv4.netfilter.ip_conntrack_max >  net.ipv4.netfilter.ip_conntrack_count

यदि अधिकतम == गणना, आपका अधिकतम कनेक्शन भरा हुआ है और आपका लिनक्स-बॉक्स नए कनेक्शन को स्वीकार नहीं कर सकता है।
यदि आपके पास ip_conntrack नहीं है, तो आप आसानी से लोड कर सकते हैंmodprobe ip_conntrack

— अरब की खाड़ी
स्रोत

2

और अगर यह मामला है, तो आपको उसके लिए कनेक्शन ट्रैकिंग को रोकने के लिए 'कच्चे' तालिका में NOTRACK लक्ष्य को देखना चाहिए। मैंने हाल ही में एक व्यस्त DNS सर्वर के लिए किया था और इसने iptables को अड़चन से हटा दिया और DNS रिज़ॉल्यूशन टाइमआउट का कारण बना।

— कैमरन केर

और यहाँ एक उदाहरण है कि कैसे मैंने नोटरी नियमों का उपयोग करते हुए IPTables को यूडीपी डीएनएस के लिए कोई कनेक्शन ट्रैकिंग नहीं किया। distracted-it.blogspot.co.nz/2015/05/…

— कैमरून केर

1

मुझे संदेह है कि प्राप्त पक्ष केवल पैकेट दर को संभालने में सक्षम नहीं है और यहां बताया गया है:

क्लाइंट पर tcpdump का उपयोग करने से गिरा हुआ पैकेट कम हो जाता है: tcpdump क्लाइंट को धीमा कर रहा है और इसलिए सर्वर बहुत कम पैकर दर देख रहा है जिसे वह अभी भी आंशिक रूप से संभाल सकता है। आपको क्लाइंट और सर्वर दोनों पर RX / TX पैकेट काउंटर की जाँच करके इस परिकल्पना की पुष्टि करने में सक्षम होना चाहिए
आपने उल्लेख किया है कि आपने यूडीपी बफर प्राप्त / भेजने का आकार बढ़ाया, क्या आप विस्तार कर सकते हैं कि कैसे? यह महत्वपूर्ण है कि सर्वर पर आप rmem_max और rmem_default दोनों को बदलें , उदाहरण: sysctl -w net.core.rmem_max=524287 sysctl -w net.core.wmem_max=524287 sysctl -w net.core.rmem_default=524287 sysctl -w net.core.wmem_default=524287

अपनी सेटिंग्स का परीक्षण

आँकड़े और नोड अनुप्रयोग बंद करो, तो सिस्टम निष्क्रिय के साथ पैकेट दर का परीक्षण करने के लिए iperf का उपयोग करें जिसे नेटवर्क / कर्नेल संभाल सकता है। यदि आप iperf के साथ 40K पैकेट / s स्ट्रीम कर सकते हैं, लेकिन आँकड़ों के साथ नहीं कर सकते हैं तो आपको आँकड़ों के ट्यूनिंग पर अपने प्रयासों को केंद्रित करना चाहिए।

अन्य ट्यूनबल्स

यह भी याद रखें कि net.core.netdev_max_backlog को ट्यून करें : किसी विशेष इंटरफ़ेस द्वारा प्राप्त कर्नेल की तुलना में तेज़ी से पैकेट प्राप्त करने पर अधिकतम संख्या में पैकेटों को कतार में लाने की अनुमति मिलती है।

— unicoletti
स्रोत