सवाल ज़ेन के तहत टीसीपी स्वीकार () प्रदर्शन इतना बुरा क्यों है?


जिस दर पर मेरा सर्वर स्वीकार कर सकता है () नए आने वाले टीसीपी कनेक्शन ज़ेन के तहत वास्तव में खराब है। नंगे धातु हार्डवेयर पर एक ही परीक्षण 3-5x गति अप दिखाता है।

  1. ज़ेन के नीचे यह कितना बुरा है?
  2. क्या आप नए टीसीपी कनेक्शन के प्रदर्शन में सुधार करने के लिए ज़ेन को ट्विक कर सकते हैं?
  3. क्या इस तरह के उपयोग-मामले के लिए अन्य वर्चुअलाइजेशन प्लेटफॉर्म बेहतर अनुकूल हैं?

पृष्ठभूमि

हाल ही में मैं ज़ेन के तहत चल रहे एक घर के विकसित जावा सर्वर की कुछ प्रदर्शन बाधाओं का शोध कर रहा हूं। सर्वर HTTP बोलता है और सरल टीसीपी कनेक्ट / अनुरोध / प्रतिक्रिया / डिस्कनेक्ट कॉल का जवाब देता है।

लेकिन सर्वर पर यातायात के बोतलबंद भेजने के दौरान भी, यह प्रति सेकंड ~ 7000 से अधिक टीसीपी कनेक्शन स्वीकार नहीं कर सकता है (8-कोर ईसी 2 इंस्टेंस पर, सी 1। एक्सलर्जिंग जेन चल रहा है)। परीक्षण के दौरान, सर्वर एक अजीब व्यवहार भी प्रदर्शित करता है जहां एक कोर (जरूरी नहीं सीपीयू 0) बहुत लोड हो जाता है> 80%, जबकि अन्य कोर लगभग निष्क्रिय रहते हैं। इससे मुझे लगता है कि समस्या कर्नेल / अंतर्निहित वर्चुअलाइजेशन से संबंधित है।

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

ज़ेन इंस्टेंस पर फिर से, मैंने sysctl.conf में लगभग हर सेटिंग को सक्षम / ट्विक करने का प्रयास किया है। सक्षम करने सहित पैकेट स्टीयरिंग प्राप्त करें तथा फ्लो स्टीयरिंग प्राप्त करें और सीपीयू को धागे / प्रक्रियाओं को पिन करना लेकिन बिना किसी स्पष्ट लाभ के।

मुझे पता है कि वर्चुअलाइज्ड चलते समय खराब प्रदर्शन की उम्मीद की जा सकती है। लेकिन इस डिग्री के लिए? एक धीमी, नंगे धातु सर्वर virtperforming virt। 5-कारक द्वारा 8-कोर?

  1. क्या यह ज़ेन के वास्तव में अपेक्षित व्यवहार है?
  2. क्या आप नए टीसीपी कनेक्शन के प्रदर्शन में सुधार करने के लिए ज़ेन को ट्विक कर सकते हैं?
  3. क्या इस तरह के उपयोग-मामले के लिए अन्य वर्चुअलाइजेशन प्लेटफॉर्म बेहतर अनुकूल हैं?

इस व्यवहार को पुन: उत्पन्न करना

जब इसकी जांच और समस्या को इंगित करते हुए मुझे पता चला कि netperf प्रदर्शन परीक्षण उपकरण उसी अनुभव को अनुकरण कर सकता है जिसका मैं अनुभव कर रहा हूं। नेटपरफ़ के टीसीपी_Cआरआर परीक्षण का उपयोग करके मैंने विभिन्न सर्वरों (वर्चुअलाइज्ड और गैर-वर्च दोनों) से विभिन्न रिपोर्ट एकत्र की हैं। यदि आप कुछ निष्कर्षों के साथ योगदान देना चाहते हैं या मेरी वर्तमान रिपोर्ट देखना चाहते हैं, तो कृपया देखें https://gist.github.com/985475

मुझे कैसे पता चलेगा कि यह समस्या खराब लिखित सॉफ्टवेयर के कारण नहीं है?

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

यह महत्वपूर्ण क्यों है?

पर ESN (मेरे नियोक्ता) मैं परियोजना का नेतृत्व कर रहा हूँ Beaconpush, जावा में लिखा एक धूमकेतु / वेब सॉकेट सर्वर। भले ही यह बहुत ही सक्षम है और इष्टतम स्थितियों के तहत इसे दी गई लगभग किसी भी बैंडविड्थ को संतृप्त कर सकता है, फिर भी यह अभी तक सीमित है कि नए टीसीपी कनेक्शन कितने तेज़ किए जा सकते हैं। यही है, यदि आपके पास एक बड़ा उपयोगकर्ता मंथन है जहां उपयोगकर्ता आते हैं और अक्सर जाते हैं, तो कई टीसीपी कनेक्शनों को स्थापित / स्थापित करना होगा। हम जितनी देर तक संभव हो सके इस कनेक्शन को जीवित रखने की कोशिश करते हैं। लेकिन अंत में, स्वीकृति () प्रदर्शन हमारे कोर को कताई से रोकता है और हमें यह पसंद नहीं है।


अद्यतन 1

कोई व्यक्ति हैकर न्यूज को यह प्रश्न पोस्ट किया, वहां कुछ प्रश्न / उत्तर भी हैं। लेकिन मैं इस प्रश्न को अद्यतित जानकारी के साथ अद्यतित रखने की कोशिश करूंगा जैसा कि मैं साथ जाता हूं।

हार्डवेयर / प्लेटफॉर्म मैंने इसका परीक्षण किया है:

  • उदाहरण के साथ ईसी 2 c1.xlarge (8 कोर, 7 जीबी रैम) और सीसी 1.4xlarge (2x इंटेल ज़ीऑन X5570, 23 जीबी रैम)। AMI का उपयोग क्रमश: ami-08f40561 और ami-1cad5275 था। किसी ने यह भी बताया कि "सुरक्षा समूह" (यानी ईसी 2 फ़ायरवॉल) भी प्रभावित हो सकता है। लेकिन इस परीक्षण परिदृश्य के लिए, मैंने स्थानीय कारकों पर इस तरह के बाहरी कारकों को खत्म करने की कोशिश की है। एक और अफवाह मैंने सुना है कि ईसी 2 उदाहरण 100k से अधिक पीपीएस को धक्का नहीं दे सकते हैं।
  • ज़ेन चलाने वाले दो निजी वर्चुअलाइज्ड सर्वर। परीक्षण से पहले शून्य लोड था लेकिन कोई फर्क नहीं पड़ता।
  • रैक स्पेस पर निजी समर्पित, ज़ेन-सर्वर। वही परिणाम के बारे में।

मैं इन परीक्षणों को फिर से चलाने और रिपोर्ट को भरने की प्रक्रिया में हूं https://gist.github.com/985475 अगर आप मदद करना चाहते हैं, तो अपनी संख्या का योगदान दें। यह आसान है!

(कार्य योजना को एक अलग, समेकित उत्तर में स्थानांतरित कर दिया गया है)


87
2018-05-22 16:39


मूल


उत्कृष्ट समस्या किसी मुद्दे पर इंगित करती है, लेकिन मेरा मानना ​​है कि आपको ज़ेन-विशिष्ट मेलिंग सूची, समर्थन फ़ोरम या यहां तक ​​कि यहां तक ​​कि बेहतर प्रदर्शन किया जाएगा xensource बग रिपोर्ट साइट। मेरा मानना ​​है कि यह कुछ शेड्यूलर बग हो सकता है - यदि आप अपने 7,000 कनेक्शन * 4 कोर / 0.80 सीपीयू लोड लेते हैं तो आपको बिल्कुल 35,000 मिलते हैं - 4 कोर पूरी तरह से संतृप्त होने पर आपको प्राप्त होने वाली संख्या। - the-wabbit
आह, और एक और बात: यदि आप कर सकते हैं, तो अपने अतिथि के लिए एक अलग (अधिक हाल ही में) कर्नेल संस्करण आज़माएं। - the-wabbit
@ syneticon-dj धन्यवाद। मैंने इसे AC2 पर कर्नेल 2.6.38 के साथ cc1.4xlarge पर आज़माया। अगर मैं गलत नहीं हूं तो मैंने लगभग ~ 10% की वृद्धि देखी। लेकिन यह उस उदाहरण प्रकार के बीफियर हार्डवेयर के कारण अधिक संभावना है। - cgbystrom
एचएन प्रतिक्रियाओं के साथ इसे अद्यतित रखने के लिए धन्यवाद, यह एक अच्छा सवाल है। मैं सुझाव देता हूं कि कार्य योजना को एक समेकित उत्तर में संभवतः स्थानांतरित करना है - क्योंकि ये समस्या के सभी संभावित उत्तर हैं। - Jeff Atwood
@jeff एक्शन प्लान ले जाएं, चेक करें। - cgbystrom


जवाब:


अभी: छोटे पैकेट प्रदर्शन ज़ेन के नीचे बेकार है

(प्रश्न से खुद को अलग जवाब में ले जाया गया)

एचएन (एक केवीएम डेवलपर?) पर किसी उपयोगकर्ता के अनुसार यह ज़ेन और केवीएम में छोटे पैकेट प्रदर्शन के कारण है। यह वर्चुअलाइजेशन के साथ एक ज्ञात समस्या है और उसके अनुसार, वीएमवेयर का ईएसएक्स इसे बेहतर तरीके से संभालता है। उन्होंने यह भी ध्यान दिया कि केवीएम कुछ नई सुविधाओं को ला रहा है जो इसे कम करता है (मूल पोस्ट)।

यदि यह सही है तो यह जानकारी थोड़ा हतोत्साहित है। किसी भी तरह से, मैं नीचे दिए गए चरणों का प्रयास करूंगा जब तक कि कुछ ज़ेन गुरु एक निश्चित उत्तर के साथ नहीं आते :)

Xen-users मेलिंग सूची से Iain Kay इस ग्राफ को संकलित किया: netperf graph TCP_CRR बार पर ध्यान दें, "2.6.18-239.9.1.el5" बनाम "2.6.39 (ज़ेन 4.1.0 के साथ)" की तुलना करें।

यहां और उससे प्रतिक्रियाओं / उत्तरों के आधार पर वर्तमान कार्य योजना HN:

  1. इस समस्या को ज़ेन-विशिष्ट मेलिंग सूची और syenson-dj द्वारा सुझाए गए xensource के बगजिला में सबमिट करेंसंदेश xen-user सूची में पोस्ट किया गया था, उत्तर की प्रतीक्षा।

  2. एक साधारण रोगजनक, अनुप्रयोग-स्तर परीक्षण केस बनाएं और इसे प्रकाशित करें।
    निर्देशों के साथ एक परीक्षण सर्वर बनाया गया है और गिटहब को प्रकाशित। इसके साथ आप netperf की तुलना में एक और वास्तविक दुनिया उपयोग-मामले देखने में सक्षम होना चाहिए।

  3. 32-बिट पीवी ज़ेन अतिथि उदाहरण का प्रयास करें, क्योंकि 64-बिट ज़ेन में अधिक ओवरहेड का कारण बन सकता है। किसी ने एचएन पर इसका उल्लेख किया। कोई फर्क नहीं पड़ता।

  4. Net.ipv4.tcp_syncookies को sysctl.conf में सक्षम करने का प्रयास करें जैसा कि एचएन पर abofh द्वारा सुझाया गया है। यह स्पष्ट रूप से पराक्रम कर्नेल में हैंडशेक होने के बाद से प्रदर्शन में सुधार होगा। मुझे इसके साथ कोई भाग्य नहीं था।

  5. 1024 से बैकलॉग को कुछ अधिक तक बढ़ाएं, एचएन पर अबोफ द्वारा भी सुझाव दिया गया है। यह भी मदद कर सकता है क्योंकि अतिथि dom0 (मेजबान) द्वारा दिए गए निष्पादन टुकड़े के दौरान संभावित रूप से () अधिक कनेक्शन स्वीकार कर सकता है।

  6. डबल-चेक करें कि सभी मशीनों पर कॉनट्रैक अक्षम है क्योंकि यह स्वीकृति दर को कम कर सकता है (deubeulyou द्वारा सुझाया गया)। हां, यह सभी परीक्षणों में अक्षम कर दिया गया था।

  7. नेटस्टैट-एस में "सुनो कतार ओवरफ्लो और सिंकैच बाल्टी ओवरफ्लो" के लिए जांचें (एचएन पर माइक_सेपे द्वारा सुझाया गया)।

  8. कई कोरों के बीच इंटरप्ट हैंडलिंग को विभाजित करें (आरपीएस / आरएफएस मैंने पहले सक्षम करने की कोशिश की है, ऐसा करने के लिए माना जाता है, लेकिन फिर कोशिश करने लायक हो सकता है)। एचएन में adamt द्वारा सुझाया गया।

  9. मैट बेली द्वारा सुझाए गए अनुसार टीसीपी सेगमेंटेशन ऑफलोड और स्कैटर / एक्सेलेरेशन इकट्ठा करना बंद करें। (ईसी 2 या इसी तरह के वीपीएस मेजबान पर संभव नहीं है)


26
2018-05-22 23:41



+1 जब आप पता चला तो प्रदर्शन परिणामों को निश्चित रूप से पोस्ट करें! - chrisaycock
इस सवाल के बारे में किसी ने मुझे ट्विटर पर पोक किया। दुर्भाग्य से, ऐसा लगता है क्योंकि यह समस्या बनी रहती है। मैंने पिछले साल से ज्यादा शोध नहीं किया है। इस समय के दौरान ज़ेन मई में सुधार हुआ है, मुझे नहीं पता। केवीएम डेवलपर ने यह भी बताया कि वे इस तरह के मुद्दों को संबोधित कर रहे थे। पीछा करने लायक हो सकता है। साथ ही, मैंने सुना है कि एक और सिफारिश ज़ेन / केवीएम के बजाय ओपनवीजेड को आजमाएं क्योंकि इसमें कम या कोई लेयरिंग / सिस्कोल के अवरोध शामिल नहीं हैं। - cgbystrom


अनजाने में, मैंने पाया कि एनआईसी हार्डवेयर त्वरण को बंद करना ज़ेन नियंत्रक (एलएक्ससी के लिए भी सच) पर नेटवर्क प्रदर्शन में काफी सुधार करता है:

स्कैटर-इकट्ठा एक्सेल:

/usr/sbin/ethtool -K br0 sg off

टीसीपी सेगमेंटेशन ऑफ़लोड:

/usr/sbin/ethtool -K br0 tso off

जहां br0 हाइपरवाइजर होस्ट पर आपका पुल या नेटवर्क डिवाइस है। आपको प्रत्येक बूट पर इसे बंद करने के लिए इसे सेट अप करना होगा। YMMV।


20
2018-05-22 19:09



मैं इसके समर्थन में हूं। मेरे पास ज़ेन पर चल रहा एक विंडोज 2003 सर्वर था जो उच्च थ्रूपुट स्थितियों के तहत कुछ भयानक पैकेट हानि समस्याओं का सामना करना पड़ा। जब मैंने टीसीपी सेगमेंट ऑफलोड को अक्षम कर दिया तो समस्या दूर हो गई - rupello
धन्यवाद। मैंने आपके सुझावों के साथ मूल प्रश्न में "कार्य योजना" अपडेट की है। - cgbystrom
यह भी देखें cloudnull.io/2012/07/xenserver-network-tuning - Lari Hotari


हो सकता है कि आप थोड़ा सा स्पष्टीकरण दे सकें - क्या आपने ज़ेन के तहत अपने सर्वर पर परीक्षण चलाया था, या केवल ईसी 2 इंस्टेंस पर?

स्वीकार्य सिर्फ एक और सिस्कल है, और नए कनेक्शन केवल अलग हैं कि पहले कुछ पैकेट में कुछ विशिष्ट झंडे होंगे - एक हाइपरवाइजर जैसे ज़ेन को निश्चित रूप से कोई अंतर नहीं दिखना चाहिए। आपके सेटअप के अन्य भाग शायद: ईसी 2 में उदाहरण के लिए, मुझे आश्चर्य नहीं होगा अगर सुरक्षा समूहों के पास इसके साथ कुछ करना है; conntrack भी है नए कनेक्शन स्वीकार करने की दर को रेट करने की सूचना दी (पीडीएफ)

अंत में, ऐसा लगता है कि सीपीयू / कर्नेल संयोजन हैं जो ईसी 2 (और शायद सामान्य रूप से ज़ेन) पर अजीब CPU उपयोग / हैंगअप का कारण बनते हैं हाल ही में लिब्रेटो द्वारा ब्लॉग किया गया


2
2018-05-22 19:56



मैंने सवाल अपडेट किया और स्पष्ट किया कि मैंने किस हार्डवेयर पर कोशिश की है। abofh ने अतिथि के लिए निष्पादन टुकड़ा के दौरान संभावित स्वीकृति () एस की संख्या को तेज़ करने के लिए 1024 से आगे बैकलॉग को बढ़ाने का भी सुझाव दिया। Conntrack के बारे में, मुझे निश्चित रूप से दोबारा जांच करनी चाहिए कि ऐसी चीजें अक्षम हैं, धन्यवाद। मैंने लिबेरेटो लेख पढ़ा है लेकिन विभिन्न हार्डवेयर की मात्रा को देखते हुए मैंने यह कोशिश की, यह मामला नहीं होना चाहिए। - cgbystrom


सुनिश्चित करें कि आपने dom0 में ब्रिजिंग कोड में iptables और अन्य हुक अक्षम कर दिए हैं। जाहिर है यह केवल पुल नेटवर्किंग ज़ेन सेटअप पर लागू होता है।

echo 0 > /proc/sys/net/bridge/bridge-nf-call-ip6tables
echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables
echo 0 > /proc/sys/net/bridge.bridge-nf-call-arptables

यह सर्वर के आकार पर निर्भर करता है लेकिन छोटे (4-कोर प्रोसेसर) पर एक सीपीयू कोर को ज़ेन डोम 0 को समर्पित करता है और पिन करता है। Hypervisor बूट विकल्प:

dom0_max_vcpus=1 dom0_vcpus_pin dom0_mem=<at least 512M>

क्या आपने डोमू को भौतिक ईथरनेट पीसीआई डिवाइस पास करने का प्रयास किया था? अच्छा प्रदर्शन बढ़ावा होना चाहिए।


0
2018-02-11 11:35