سؤال لماذا يقبل TCP () أداءً سيئًا للغاية في ظل Xen؟


المعدل الذي يمكن أن يقبل به خادم () اتصالات TCP الجديدة الواردة هو أمر سيء للغاية في ظل Xen. نفس الاختبار على الأجهزة المعدنية العارية يظهر سرعة تصل إلى 3-5x.

  1. كيف يكون هذا سيئًا للغاية تحت حكم زين؟
  2. هل يمكنك تعديل Xen لتحسين الأداء لاتصالات TCP الجديدة؟
  3. هل هناك منصات افتراضية أخرى تناسب هذا النوع من حالات الاستخدام؟

خلفية

لقد قمت مؤخرا بالبحث عن بعض اختناقات الأداء في خادم جافا تم إنشاؤه داخليا تحت نظام Xen. يقوم الخادم بنقل HTTP ويقوم بالرد على مكالمات اتصال / طلب / استجابة / قطع اتصال TCP بسيطة.

ولكن حتى أثناء إرسال حمولات السفن إلى الخادم ، فإنه لا يمكن قبول أكثر من 7000 توصيلة TCP في الثانية (على مثيل EC2 8-core ، c1.xlarge الذي يعمل بنظام Xen). أثناء الاختبار ، يظهر الخادم أيضًا سلوكًا غريبًا حيث يتم تحميل وحدة أساسية واحدة (وليس بالضرورة وحدة المعالجة المركزية 0) جدًا> 80٪ ، بينما تبقى النوى الأخرى خامدة تقريبًا. هذا يقودني إلى الاعتقاد بأن المشكلة مرتبطة بالنواة الافتراضية.

عند اختبار نفس السيناريو على المعدن العاري ، تظهر منصة غير افتراضية أحصل على نتائج اختبار توضح قبول TCP () لمعدلات تتجاوز 35000 / ثانية. هذا على جهاز Core i5 4 يعمل بنظام Ubuntu مع جميع النوى المشبعة بالكامل تقريبًا. بالنسبة لي هذا النوع من الشخصيات يبدو صحيحًا.

على سبيل المثال Xen مرة أخرى ، لقد حاولت تمكين / قرص تقريبا كل الإعدادات هناك في sysctl.conf. بما في ذلك التمكين تلقي حزمة التوجيه و تلقي تدفق التوجيه وتثبيت مؤشرات الترابط / العمليات على وحدات المعالجة المركزية (CPU) ولكن بدون مكاسب ظاهرية.

أنا أعلم أن الأداء المتدهور هو المتوقع عند تشغيل المحاكاة الافتراضية. لكن إلى هذه الدرجة؟ A أبطأ ، خادم معدني عارية يتفوق الأداء الفضي. 8-النواة بمعامل 5؟

  1. هل هذا السلوك المتوقع حقاً لـ Xen؟
  2. هل يمكنك تعديل Xen لتحسين الأداء لاتصالات TCP الجديدة؟
  3. هل هناك منصات افتراضية أخرى تناسب هذا النوع من حالات الاستخدام؟

إعادة إنتاج هذا السلوك

عندما مزيد من التحقيق في ذلك وتحديد المشكلة وجدت أن netperf أداة اختبار الأداء يمكن أن تحاكي السيناريو المماثل الذي أشعر به. باستخدام اختبار TCP_CRR netperf لقد جمعت تقارير مختلفة من خوادم مختلفة (سواء الظاهرية وغير الفضيلة.). إذا كنت ترغب في المساهمة في بعض النتائج أو البحث عن تقاريري الحالية ، يرجى الاطلاع https://gist.github.com/985475

كيف أعرف أن هذه المشكلة لا ترجع إلى البرامج المكتوبة بشكل سيء؟

  1. تم اختبار الخادم على الأجهزة المعدنية العارية وهو يشبع جميع النوى المتاحة له.
  2. عند استخدام اتصالات TCP ، تبقى المشكلة بعيدة.

لماذا هذا مهم؟

في ESN (صاحب العمل) أنا قائد المشروع Beaconpush، خادم Comet / Web Socket مكتوب بلغة Java. على الرغم من كونها ذات أداء عالي للغاية ويمكن أن تشبع أي عرض نطاق ترددي تقريبًا في ظل الظروف المثلى ، إلا أنها لا تزال محدودة في مدى سرعة إجراء اتصالات TCP الجديدة. بمعنى ، إذا كان لديك عطل كبير في المستخدم حيث يأتي المستخدمون ويذهبون كثيرًا ، فسيتعين إعداد العديد من اتصالات TCP / teared. نحن نحاول التخفيف من حدة هذه العلاقات المستمرة لأطول فترة ممكنة. ولكن في النهاية ، فإن أداء القبول () هو الذي يحافظ على غزلنا ولا ندرك ذلك.


تحديث 1

شخصا ما نشر هذا السؤال على هاكر نيوز، هناك بعض الأسئلة / الإجابات هناك كذلك. لكنني سأحاول إبقاء هذا السؤال محدثًا بالمعلومات التي أجدها أثناء متابعتي.

الأجهزة / المنصات لقد قمت باختبار هذا على:

  • EC2 مع أنواع مثيل c1.xlarge (8 النوى ، 7 غيغابايت من ذاكرة الوصول العشوائي) و cc1.4xlarge (2x Intel Xeon X5570 ، 23 غيغابايت من ذاكرة الوصول العشوائي). استخدمت AMIs ami-08f40561 و ami-1cad5275 على التوالي. أشار أحدهم أيضًا إلى أن "مجموعات الأمان" (مثل EC2s firewall) قد تؤثر أيضًا. ولكن في سيناريو الاختبار هذا ، حاولت فقط على المضيف المحلي لإزالة العوامل الخارجية مثل هذا. الشائعات الأخرى التي سمعتها هي أن حالات EC2 لا يمكنها دفع أكثر من 100 ألف PPS.
  • اثنين من خادم الافتراضية الخاصة تشغيل Xen. كان لدى أحدهم حمولة صفر قبل الاختبار ولكن لم يحدث أي فرق.
  • خاص مكرس ، خادم Xen في Rackspace. حول نفس النتائج هناك.

أنا بصدد إعادة تشغيل هذه الاختبارات وتعبئة التقارير في https://gist.github.com/985475 إذا كنت ترغب في المساعدة ، شارك بأرقامك. من السهل!

(تم نقل خطة العمل إلى إجابة منفصلة وموحدة)


87
2018-05-22 16:39


الأصل


وظيفة ممتازة في تحديد المشكلة ، ولكن أعتقد أنك ستخدم بشكل أفضل على قائمة بريدية خاصة بـ Xen أو منتدى الدعم أو حتى xensource تقرير موقع علة. أعتقد أن هذا قد يكون بعض الأخطاء في جدولة - إذا كنت تأخذ عددًا من اتصالاتك التي يبلغ عددها 7000 * 4 محاور / 0.80 وحدة معالجات وحدة المعالجة المركزية التي تحصل عليها تمامًا 35000 - الرقم الذي ستحصل عليه عندما يكون 4 نوى مشبعة تمامًا. - the-wabbit
آه ، وشيء آخر: جرّب إصدارًا مختلفًا (ربما أحدث) للنواة لضيفك ، إذا كنت تستطيع ذلك. - the-wabbit
@ syneticon-dj شكرًا. لقد جربته على cc1.4xlarge في EC2 مع kernel 2.6.38. رأيت حول زيادة ~ 10 ٪ إذا لم أكن مخطئا. ولكن من المرجح أكثر بسبب الأجهزة beefier من هذا النوع من المثيلات. - cgbystrom
شكرا على إبقاء هذا مستجدا مع ردود HN ، إنه سؤال عظيم. أقترح نقل خطة العمل إلى إجابة موحدة ، ربما - لأن هذه كلها إجابات محتملة للمشكلة. - Jeff Atwood
jeff تحرك خطة العمل ، تحقق. - cgbystrom


الأجوبة:


الحق الآن: أداء حزمة صغيرة تمتص تحت كسين

(انتقل من السؤال نفسه إلى إجابة منفصلة بدلا من ذلك)

وفقا لمستخدم على HN (مطور KVM؟) وهذا يرجع إلى أداء الحزم الصغيرة في Xen وأيضا KVM. إنها مشكلة معروفة في المحاكاة الافتراضية ووفقًا له ، فإن ESX في برنامج VMWare يعالج ذلك بشكل أفضل. كما أشار إلى أن KVM يجلب بعض الميزات الجديدة المصممة للتخفيف من هذا (المشاركة الأصلية).

هذه المعلومات غير مشجعة بعض الشيء إذا كانت صحيحة. في كلتا الحالتين ، سأحاول الخطوات أدناه حتى يأتي بعض Xen المعلم جنبا إلى جنب مع إجابة نهائية :)

قام Iain Kay من القائمة البريدية لمستخدمي xen بتجميع هذا الرسم البياني: netperf graph لاحظ أشرطة TCP_CRR ، قارن "2.6.18-239.9.1.el5" مقابل "2.6.39 (مع Xen 4.1.0)".

خطة العمل الحالية على أساس الردود / الإجابات هنا ومن HN:

  1. إرسال هذه القضية إلى قائمة بريدية خاصة ب Xen و bugzilla xensource كما هو مقترح بواسطة syneticon-dj ا تم نشر الرسالة إلى قائمة xen-user، في انتظار الرد.

  2. قم بإنشاء حالة اختبار مرضية بسيطة على مستوى التطبيق ونشرها.
    تم إنشاء خادم اختبار مع تعليمات و نشرت ل GitHub. مع هذا يجب أن تكون قادراً على رؤية حالة استخدام أكثر واقعية مقارنة بـ netperf.

  3. جرّب مثيل ضيف PV Xen 32 بت ، حيث قد يتسبب 64 بت في زيادة الحمل في Xen. ذكر أحدهم هذا على HN. لم تحدث فرقا.

  4. حاول تمكين net.ipv4.tcp_syncookies في sysctl.conf كما اقترح من قبل abofh على HN. هذا على ما يبدو ربما تحسين الأداء منذ حدوث مصافحة في النواة. لم يكن لدي أي حظ مع هذا.

  5. زيادة تراكم من 1024 إلى شيء أعلى من ذلك بكثير ، اقترح أيضا من قبل abofh على HN. وقد يساعد هذا أيضًا على احتمال قبول الضيف () لمزيد من الاتصالات أثناء شريحة التنفيذ التي يقدمها dom0 (المضيف).

  6. تحقق جيدًا من أن conntrack معطل على جميع الأجهزة حيث يمكن أن يقلل معدل القبول إلى النصف (اقترحه deubeulyou). نعم ، تم تعطيله في جميع الاختبارات.

  7. تحقق من "قوائم انتظار تجاوز الفواصل والمزامنة في قائمة الانتظار في netstat -s" (مقترح بواسطة mike_esspe على HN).

  8. تقسيم التعامل مع المقاطعة بين مراكز متعددة (RPS / RFS لقد حاولت التمكين في وقت سابق من المفترض أن تفعل ذلك ، ولكن قد تكون تستحق المحاولة مرة أخرى). اقترح من قبل adamt في HN.

  9. إيقاف تشغيل إلغاء تحميل تجزئة TCP وتسارع / تجميع التسارع كما اقترح مات بيلي. (غير ممكن في EC2 أو مضيف VPS مماثل)


26
2018-05-22 23:41



+1 بالتأكيد نشر نتائج الأداء عندما اكتشفت! - chrisaycock
طعنني شخص ما على تويتر بخصوص هذا السؤال. للأسف ، يبدو أن هذه المشاكل لا تزال قائمة. لم أدخل الكثير من الأبحاث منذ العام الماضي. تحسنت Xen MAY خلال هذا الوقت ، لا أعرف. وذكر المطور KVM أيضا أنهم كانوا يعالجون قضايا مثل هذه. يمكن أن تكون جديرة بالمتابعة. أيضًا ، هناك توصية أخرى سمعتها هي تجربة OpenVZ بدلاً من Xen / KVM نظرًا لأنها تضيف تراكبًا أو اعتراضًا أقل من طبقات syscalls. - cgbystrom


رواية ، وجدت أن إيقاف تسريع أجهزة NIC يحسن بشكل كبير من أداء الشبكة على وحدة تحكم Xen (ينطبق أيضًا على LXC):

تجميع مبعثر - تجميع:

/usr/sbin/ethtool -K br0 sg off

إلغاء تحميل TCP TCP:

/usr/sbin/ethtool -K br0 tso off

حيث br0 هو الجسر الخاص بك أو جهاز الشبكة على المضيف hypervisor. سيكون عليك إعداد هذا لإيقاف تشغيله عند كل تمهيد. YMMV.


20
2018-05-22 19:09



أنا ثاني هذا. كان لدي خادم Windows 2003 يعمل على Xen الذي عانى من بعض مشاكل فقدان الرهيب في ظل ظروف الإنتاجية العالية. ذهبت المشكلة بعيدا عندما قمت بتعطيل إلغاء تحميل قطاع TCP - rupello
شكر. لقد قمت بتحديث "خطة العمل" في السؤال الأصلي مع اقتراحاتك. - cgbystrom
أنظر أيضا cloudnull.io/2012/07/xenserver-network-tuning - Lari Hotari


ربما يمكنك توضيح بعض الشيء - هل قمت بإجراء الاختبارات تحت Xen على خادمك الخاص ، أم فقط على مثيل EC2؟

القبول هو فقط syscall آخر ، والوصلات الجديدة تختلف فقط في أن الحزم القليلة الأولى سيكون لها بعض الأعلام المحددة - لا شك أن المشرف مثل Xen لا يرى أي فرق. قد تكون أجزاء أخرى من الإعداد الخاص بك: في EC2 على سبيل المثال ، لن أكون مندهشًا إذا كان لدى مجموعات الأمان علاقة بها ؛ conntrack هو أيضا الإبلاغ عن خفض معدل قبول الاتصالات الجديدة (PDF).

وأخيرا ، يبدو أن هناك مجموعات وحدة المعالجة المركزية / Kernel التي تسبب استخدام CPU غريب / hangups على EC2 (وربما Xen بشكل عام) ، كما المدونة عن طريق Librato في الآونة الأخيرة.


2
2018-05-22 19:56



لقد قمت بتحديث السؤال وقمت بتوضيح الأجهزة التي جربتها. كما اقترح أبووف زيادة العمل المتراكم لما بعد 1024 لتسريع عدد () s المقبولة خلال شريحة التنفيذ للضيف. فيما يتعلق conntrack ، ينبغي لي بالتأكيد التحقق من أن مثل هذه الأمور معطلة ، وذلك بفضل. لقد قرأت مقالة ليبراتو ، ولكن بالنظر إلى كمية الأجهزة المختلفة التي جربتها ، لا ينبغي أن يكون الأمر كذلك. - cgbystrom


تأكد من تعطيل iptables وخطافات أخرى في سد رمز في dom0. من الواضح أنه لا ينطبق إلا على الجسر إعداد شبكة Xen.

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

يعتمد ذلك على حجم الخادم ولكن على وحدات أصغر (معالج رباعي النواة) يخصص أحد وحدات المعالجة المركزية الأساسية لـ Xen dom0 ويعلقه. خيارات التمهيد Hypervisor:

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

هل حاولت أن تمر جهاز PCI ethernet PCI إلى domU؟ يجب أن يكون هناك دفعة جيدة الأداء.


0
2018-02-11 11:35