Soru Xen altında TCP kabul () performansı neden bu kadar kötü?


Sunucumun yeni gelen TCP bağlantılarını kabul edebileceği oran Xen altında gerçekten kötü. Çıplak metal donanımda aynı test 3-5x hız artışları gösteriyor.

  1. Bu nasıl Xen altında bu kadar kötü?
  2. Yeni TCP bağlantıları için performansı geliştirmek için Xen'i ayarlayabilir misiniz?
  3. Bu tür kullanım için daha uygun başka sanallaştırma platformları var mı?

Arka fon

Son zamanlarda Xen altında çalışan bir şirket içi Java sunucusunun performans darboğazlarını araştırıyorum. Sunucu, HTTP'yi konuşuyor ve basit TCP bağlantısı / istek / yanıt / bağlantı kesme çağrılarını yanıtlıyor.

Ancak, sunucuya giden tekne yüklerini gönderirken bile, saniyede 7000'den fazla TCP bağlantılarını kabul edemez (8 çekirdekli bir EC2 örneğinde, X1 çalıştıran c1.xlarge). Test sırasında, sunucu aynı zamanda garip bir davranış sergiliyor ve bir çekirdekli (zorunlu olarak cpu 0 değil)% 80 daha fazla yüklenirken, diğer çekirdekler neredeyse boşta kalıyor. Bu, sorunun çekirdek / altta yatan sanallaştırma ile ilgili olduğunu düşünmeme yol açıyor.

Aynı senaryonun çıplak bir metal üzerinde sanallaştırılmamış bir platformda test edilmesi sırasında, test sonuçlarını 35,000 / saniyenin ötesinde TCP accept () oranlarını gösteriyorum. Bu, tüm çekirdekli Ubuntu'yu çalıştıran Core i5 4 çekirdekli makinede neredeyse tamamen doygun. Bana göre bu tür bir şey doğru görünüyor.

Yine Xen örneğinde, hemen hemen her ayarın sysctl.conf içinde etkin olmasını / ayarlanmasını denedim. Etkinleştirme dahil Paket Direksiyon Alma ve Akış Direksiyonunu Alma ve iş parçacığı / işlemleri CPU'lara sabitleme, ancak görünür kazançlar olmadan.

Sanallaştırılmış çalıştırıldığında bozulmuş performansın bekleneceğini biliyorum. Ama bu dereceye kadar mı? Daha yavaş, çıplak bir metal sunucu daha iyi performans sergiledi. 8 çekirdekli 5 faktöre mi?

  1. Xen'in bu gerçekten beklenen bir davranışı mı?
  2. Yeni TCP bağlantıları için performansı geliştirmek için Xen'i ayarlayabilir misiniz?
  3. Bu tür kullanım için daha uygun başka sanallaştırma platformları var mı?

Bu davranış yeniden üretiliyor

Bunu daha fazla araştırırken ve problemi saptadığımda, netperf Performans testi aracı, yaşadığım benzer senaryoyu simüle edebilir. Netperf'in TCP_CRR testini kullanarak farklı sunuculardan (sanallaştırılmış ve sanal olmayan) çeşitli raporlar topladım. Bazı bulgularla katkıda bulunmak veya mevcut raporlarıma bakmak istiyorsanız, lütfen bkz. https://gist.github.com/985475

Bu sorunun kötü yazılı bir yazılımdan kaynaklanmadığını nasıl bilebilirim?

  1. Sunucu, çıplak metal donanım üzerinde test edilmiştir ve neredeyse tüm çekirdeği doyurmaktadır.
  2. Canlı tutma TCP bağlantılarını kullanırken sorun gider.

Bu neden önemli?

at ESN (işverenim) Ben proje lideriyim Beaconpush, Java'da yazılmış bir Comet / Web Socket sunucusu. Her ne kadar çok performanslı olsa da ve en uygun koşullar altında verilen hemen hemen her bant genişliğini doyurabilmesine rağmen, yeni TCP bağlantılarının ne kadar hızlı yapılabileceği hala sınırlıdır. Yani, kullanıcıların çok sık geldiği ve çok sık gittiği büyük bir kullanıcı karmaşanız varsa, birçok TCP bağlantısının kurulması / dağıtılması gerekecektir. Bağlantıları olabildiğince uzun süre canlı tutmaya çalışıyoruz. Ama sonuçta, kabul () performansı, çekirdeklerimizin dönmesini engelliyor ve biz bundan hoşlanmıyoruz.


1. Güncelleme

Birisi bu soruyu Hacker News'e gönderdiOrada da bazı sorular / cevaplar var. Ama ben bu soruyu, ilerledikçe bulduğum bilgilerle güncel tutmaya çalışacağım.

Donanım / platformlar bunu test ettim:

  • Örnek türleri ile EC2, c1.xlarge (8 çekirdek, 7 GB RAM) ve cc1.4xlarge (2x Intel Xeon X5570, 23 GB RAM). AMI'ler sırasıyla ami-08f40561 ve ami-1cad5275 idi. Birisi ayrıca "Güvenlik Grupları" (yani EC2s güvenlik duvarı) 'nın da etkileyebileceğine dikkat çekti. Ancak bu test senaryosu için, sadece bunun gibi harici faktörleri ortadan kaldırmak için localhost üzerinde çalıştım. Duyduğum başka bir söylenti, EC2 örneklerinin 100k PPS'den daha fazlasını zorlayamamasıdır.
  • Xen çalıştıran iki özel sanal sunucu. Testten önce sıfır yük vardı, ancak fark yaratmadı.
  • Özel ayrılmış, Xen-server Rackspace'da. Orada aynı sonuçları hakkında.

Bu testleri yeniden yürütme ve raporları doldurma aşamasındayım. https://gist.github.com/985475 Yardım etmek isterseniz numaralarınıza katkıda bulunun. Bu kolay!

(Eylem planı ayrı, birleştirilmiş bir cevaba taşındı)


87
2018-05-22 16:39


Menşei


Bir konuya kesin olarak dikkat çeken mükemmel bir iş, ama Xen'e özgü bir e-posta listesi, destek forumu veya hatta daha iyi hizmet verileceğine inanıyorum. xensource hata raporu sitesi. Bunun bazı zamanlayıcı hataları olabileceğine inanıyorum - eğer 7,000 bağlantı numaranızı alırsanız * 4 çekirdek / 0.80 CPU yükü tam olarak 35.000 alırsınız - 4 çekirdek tam olarak doyduğunda alacağınız sayı. - the-wabbit
Ah, ve bir şey daha: Eğer misafir için farklı (daha yeni belki de) çekirdek sürümü deneyin. - the-wabbit
@ syneticon-dj Teşekkürler. Ben çekirdek 2.6.38 ile EC2 de cc1.4xlarge denedim. Yanılmıyorsam yaklaşık% 10'luk bir artış gördüm. Ancak, bu örnek türünün daha eski donanımı nedeniyle daha olasıdır. - cgbystrom
HN yanıtlarını güncel tuttuğunuz için teşekkürler, bu harika bir soru. Eylem planını muhtemelen bir cevap haline getirmeyi öneririm - çünkü bunlar sorunun olası tüm cevaplarıdır. - Jeff Atwood
@jeff Eylem planını taşıyın, kontrol edin. - cgbystrom


Cevaplar:


Şu an: Küçük paket performans Xen altında berbat

(sorudan kendisinin ayrı bir yanıt yerine taşındı)

HN'deki (KVM geliştiricisi?) Bir kullanıcıya göre bu, Xen'deki küçük paket performansından ve ayrıca KVM'den kaynaklanmaktadır. Sanallaştırmayla ilgili bilinen bir problem ve ona göre VMWare'in ESX'i bu durumu daha iyi bir hale getiriyor. Ayrıca KVM'nin bunu hafifleten bazı yeni özellikler getirdiğini de kaydetti.orijinal gönderi).

Bu bilgi doğruysa biraz cesaret kırıcıdır. Her iki şekilde de, bazı Xen guru kesin bir cevap ile birlikte gelene kadar aşağıdaki adımları deneyeceğim :)

Xen-users posta listesinden Iain Kay bu grafiği derledi: netperf graph TCP_CRR çubuklarına dikkat edin, "2.6.18-239.9.1.el5" ile "2.6.39 (Xen 4.1.0 ile)" karşılaştırması yapın.

Şu anki eylem planı / cevapları burada ve buradan alınmıştır. HN:

  1. Bu sorunu Xen'e özgü bir posta listesine ve syneticon-dj tarafından önerilen xensource'un bugzilla'sına gönderin. bir ileti xen kullanıcısı listesine gönderildi, yanıt bekliyor.

  2. Basit bir patolojik, uygulama düzeyinde bir test durumu oluşturun ve yayınlayın.
    Talimatları olan bir test sunucusu oluşturuldu ve GitHub'a yayınlandı. Bununla, netperf ile karşılaştırıldığında daha gerçek bir dünya kullanım durumunu görebilmeniz gerekir.

  3. Xen'de 64 bit daha fazla yüke neden olabileceğinden, 32 bitlik bir PV Xen konuk örneğini deneyin. Birisi bunu HN'den bahsetmişti. Fark yaratmadı.

  4. HN üzerinde abofh tarafından önerilen sysctl.conf dosyasında net.ipv4.tcp_syncookies özelliğini etkinleştirmeyi deneyin. Bu görünüşe göre belki El sıkışma çekirdeğin içinde gerçekleşeceğinden performansı artırın. Bununla hiç şansım yoktu.

  5. İşgücü 1024'ten daha yüksek bir değere yükseltin, ayrıca HN'de abofh tarafından da önerildi. Bu, misafirin dom0 (ana bilgisayar) tarafından verilen yürütme dilimi sırasında daha fazla bağlantıyı potansiyel olarak kabul edebildiği için de yardımcı olabilir.

  6. Tüm makinelerde condrack'ın devre dışı bırakıldığını kontrol edin, çünkü kabul oranını yarıya indirebilir (deubeulyou tarafından önerilmektedir). Evet, tüm testlerde devre dışı bırakıldı.

  7. "Dinleme kuyruğu taşma ve netstat -s'de kovaları taşırma" (HN'de mike_esspe tarafından önerilen) için işaretleyin.

  8. Interrupt işlemeyi çoklu çekirdekler arasında bölüştürün (Daha önce etkinleştirdiğim RPS / RFS'nin bunu yapması gerekiyordu, ancak tekrar denemeye değer olabilir). HN'de adamt tarafından önerildi.

  9. TCP segmentasyonu boşaltmak ve Matt Bailey tarafından önerilen şekilde dağılma / toplama ivme. (EC2 veya benzeri VPS sunucularında mümkün değildir)


26
2018-05-22 23:41



+1 Bunu öğrendiğinizde kesinlikle performans sonuçlarını yayınlayın! - chrisaycock
Birisi beni Twitter'da bu soruya yöneltmişti. Ne yazık ki, bu problemler devam ediyor gibi görünüyor. Geçen yıldan beri fazla araştırma yapmadım. Xen MAYIS bu süre boyunca iyileşti, bilmiyorum. KVM geliştiricisi, bunun gibi konuları ele aldıklarını da belirtti. Takip etmeye değer olabilir. Ayrıca, duyduğum başka bir öneri de Xen / KVM yerine OpenVZ'yi denemektir, çünkü daha az veya hiç bir syscall içermez. - cgbystrom


Ayrıca, NIC donanım hızlandırmasının kapatılmasının Xen kontrol ünitesindeki ağ performansını büyük ölçüde artırdığını keşfettim (LXC için de geçerli):

Dağılım-toplamak accell:

/usr/sbin/ethtool -K br0 sg off

TCP Segmentasyonunun boşaltılması:

/usr/sbin/ethtool -K br0 tso off

Br0, hiper yönetici ana bilgisayarında köprüsünüz veya ağ aygıtınız olduğunda. Her açılışta kapatmak için bunu ayarlamanız gerekecek. YMMV.


20
2018-05-22 19:09



Ben buna ikinciyim. Yüksek verimli koşullar altında bazı korkunç paket kaybı sorunları yaşadı Xen üzerinde çalışan bir Windows 2003 sunucusu vardı. TCP segmenti boşaltmayı devre dışı bıraktığımda sorun giderildi - rupello
Teşekkürler. Orijinal sorudaki "eylem planını" önerilerinizle güncelledim. - cgbystrom
Ayrıca bakınız cloudnull.io/2012/07/xenserver-network-tuning - Lari Hotari


Belki biraz açıklığa kavuşturabilirsiniz - kendi sunucunuzda ya da sadece bir EC2 örneğinde Xen altında testleri yaptınız mı?

Kabul etmek başka bir sistemdir ve yeni bağlantılar sadece ilk birkaç paketin bazı özel bayraklara sahip olması bakımından farklıdır - Xen gibi bir hiper yönetici kesinlikle bir fark görmemelidir. Kurulumunuzun diğer bölümleri: Örneğin, EC2'de Güvenlik Gruplarının bununla bir ilgisi varsa şaşırmamalı; conntrack da yeni bağlantıların kabul oranını yarıya indirdiği bildirildi (PDF).

Son olarak, EC2'de (ve genel olarak muhtemelen Xen'de) garip CPU kullanımı / kapanmasına neden olan CPU / Kernel kombinasyonları var gibi görünüyor. Son zamanlarda Librato tarafından blog yazılmıştır.


2
2018-05-22 19:56



Soruyu güncelledim ve bunu denediğim donanımı açıklığa kavuşturdum. abofh ayrıca, misafir için bir yürütme dilimi sırasında olası kabul sayısını () s artırmak için 1024 ötesindeki backlog artırılması önerdi. Conntrack ile ilgili olarak, bu tür şeylerin devre dışı kaldığını kesinlikle kontrol etmeliyim, teşekkürler. Liberato makalesini okudum ama bunu denediğim farklı donanımların miktarı göz önüne alındığında, durum böyle olmamalı. - cgbystrom


Dom0'daki köprüleme kodundaki iptables ve diğer kancaları devre dışı bıraktığınızdan emin olun. Açıkçası sadece Xen kurulum ağını köprülemek için geçerlidir.

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

Sunucunun boyutuna bağlıdır, ancak daha küçük olanlarda (4 çekirdekli işlemci) bir işlemci çekirdeğini Xen dom0'a ayırır ve sabitler. Hiper yönetici önyükleme seçenekleri:

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

Fiziksel ethernet PCI aygıtını domU'ya geçirmeyi denediniz mi? İyi bir performans artışı olmalı.


0
2018-02-11 11:35