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

1. Neden bu Xen altında bu kadar kötü?
2. Yeni TCP bağlantılarının performansını artırmak için Xen'i değiştirebilir misiniz?
3. Bu tür kullanım durumları için daha uygun başka sanallaştırma platformları var mı?

Arka fon

Son zamanlarda, Xen altında çalışan şirket içi geliştirilmiş bir Java sunucusunun performans darboğazlarını araştırıyorum. Sunucu HTTP konuşuyor ve basit TCP connect / request / response / disconnect çağrılarını yanıtlıyor.

Ancak sunucuya trafik yükleri gönderirken bile, saniyede ~ 7000'den fazla TCP bağlantısını kabul edemez (8 çekirdekli EC2 örneğinde, Xen çalışan c1.xlarge). Test sırasında, sunucu ayrıca bir çekirdeğin (zorunlu 0 cpu değil) çok fazla>% 80 yüklendiği ve diğer çekirdeklerin neredeyse boşta kaldığı tuhaf bir davranış sergiler. Bu bana sorunun çekirdek / temel sanallaştırma ile ilgili olduğunu düşündürüyor.

Aynı senaryoyu çıplak metal, sanallaştırılmamış bir platformda test ederken, TCP kabul () oranlarını 35 000 / saniye ötesinde gösteren test sonuçları alıyorum. Bu, tüm çekirdeği neredeyse tamamen doygun hale getiren Ubuntu çalıştıran Core i5 4 çekirdekli bir makinede. Bana göre bu tür rakam doğru görünüyor.

Yine Xen örneğinde sysctl.conf dosyasındaki hemen hemen her ayarı enable / tweak olarak denedim. Paket Alma Direksiyonunu Alma ve Akış Direksiyonunu etkinleştirme ve işlemcileri CPU'lara sabitleme, ancak belirgin bir kazanç olmadan sabitleme dahil.

Sanallaştırılmış çalışma sırasında düşük performans beklendiğini biliyorum. Ama bu derecede? Daha yavaş, çıplak bir metal sunucu daha iyi performans gösteriyor. 5 çekirdekli 8 çekirdekli?

1. Bu gerçekten Xen’in beklenen davranışı mı?
2. Yeni TCP bağlantılarının performansını artırmak için Xen'i değiştirebilir misiniz?
3. Bu tür kullanım durumları için daha uygun başka sanallaştırma platformları var mı?

Bu davranışı tekrarlama

Bunu daha fazla araştırırken ve sorunu tespit ederken netperf performans test aracının yaşadığım benzer senaryoyu simüle edebileceğini öğrendim. Netperf'in TCP_CRR testini kullanarak farklı sunuculardan (hem sanallaştırılmış hem de sanal olmayan) çeşitli raporlar topladım. Bazı bulgulara katkıda bulunmak veya mevcut raporlarıma bakmak istiyorsanız, lütfen https://gist.github.com/985475 adresine bakın.

Bu sorunun kötü yazılmış yazılımlardan kaynaklanmadığını nasıl bilebilirim?

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

Bu neden önemli?

At ESN (benim işveren) Ben proje kurşun duyuyorum Beaconpush , Java ile yazılmış bir Comet / Web Soket sunucusundan. Çok performans göstermesine ve optimum koşullarda verilen neredeyse tüm bant genişliğini doyurabilmesine rağmen, yeni TCP bağlantılarının ne kadar hızlı yapılabileceği ile sınırlıdır. Diğer bir deyişle, kullanıcıların çok sık gelip gittiği büyük bir kullanıcı karmaşasına sahipseniz, birçok TCP bağlantısının kurulması / parçalanması gerekir. Bu bağlantılarını mümkün olduğu kadar uzun süre canlı tutmaya çalışıyoruz. Fakat sonunda, accept () performansı, çekirdeklerimizin dönmesini engelleyen şeydir ve bundan hoşlanmıyoruz.

Güncelleme 1

Birisi bu soruyu Hacker News'e gönderdi , orada da bazı sorular / cevaplar var. Ancak, bu soruyu ilerledikçe bulabildiğim bilgilerle güncel tutmaya çalışacağım.

Bunu üzerinde test ettik donanım / platformlar:

• C1.xlarge (8 çekirdekli, 7 GB RAM) ve cc1.4xlarge (2x Intel Xeon X5570, 23 GB RAM) örnekli EC2. Kullanılan AMI'ler sırasıyla ami-08f40561 ve ami-1cad5275'tir. Birisi ayrıca "Güvenlik Grupları" nın (yani EC2'nin güvenlik duvarını) da etkileyebileceğini belirtti. Ancak bu test senaryosunda, bunun gibi dış etkenleri ortadan kaldırmak için yalnızca localhost'ta denedim. Duyduğum bir diğer söylenti, EC2 örneklerinin 100k PPS'den daha fazla zorlayamayacağı.
• Xen çalıştıran iki özel sanallaştırılmış sunucu. Biri testten önce sıfır yüke sahipti ancak bir fark yaratmadı.
• Özel, Rackspace'de Xen sunucusu. Orada aynı sonuçlar hakkında.

Bu testleri tekrar denemek ve raporları https://gist.github.com/985475 adresinden doldurmaktayım . Yardım etmek isterseniz, numaralarınıza katkıda bulunun. Bu kolay!

(Eylem planı ayrı ve konsolide bir cevaba taşınmıştır)

Şu an: Küçük paket performansı Xen'in altında kalıyor

(bunun yerine sorunun kendisinden ayrı bir cevaba taşındı)

HN'deki bir kullanıcıya (KVM geliştiricisi?) Göre bu, Xen'deki ve ayrıca KVM'deki küçük paket performansından kaynaklanmaktadır. Sanallaştırma ile ilgili bilinen bir sorun ve ona göre, VMWare ESX bunu daha iyi ele alıyor. Ayrıca KVM'nin bunu hafifletmek için tasarlanan bazı yeni özellikler getirdiğini de belirtti ( orijinal yazı ).

Bu bilgi doğru ise biraz cesaret kırıcıdır. Her iki durumda da, bazı Xen gurusu kesin bir cevapla gelene kadar aşağıdaki adımları deneyeceğim:

Xen -users e-posta listesinden Iain Kay, bu grafiği derledi: 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ını karşılaştırın.

Buradaki ve HN'den gelen cevaplara / cevaplara dayanan mevcut eylem planı :

1. Syneticon-dj tarafından önerildiği gibi Xen özgü posta listesi ve XenSource en Bugzilla'da bu sorunu gönderin Bir mesaj xen-kullanıcı listesine gönderilmiş yanıt bekliyor.

2. Basit bir patolojik, uygulama düzeyinde test durumu oluşturun ve yayınlayın.
   Talimatları içeren bir test sunucusu oluşturuldu ve GitHub'a yayınlandı . Bununla netperf'e kıyasla daha gerçek bir kullanım senaryosu görebilmelisiniz.

3. 64 bit, Xen'de daha fazla ek yüke neden olabileceğinden 32 bit PV Xen konuk örneği deneyin. Biri HN'de bundan bahsetti. Bir fark yaratmadı.

4. HN üzerinde abofh tarafından önerilen şekilde net.ipv4.tcp_syncookies komutunu sysctl.conf içinde etkinleştirmeyi deneyin. Bu görünüşte olabilir tokalaşma çekirdeğindeki oluşacak beri performansını artırmak. Bununla hiç şansım olmadı.

5. İstisnayı 1024'ten daha yüksek bir şeye yükselt, HN'de ayrıca önerildi. Bu aynı zamanda misafirin dom0 (ev sahibi) tarafından verilen yürütme dilimi sırasında daha fazla bağlantı kabul edebileceğinden () daha fazla bağlantı kabul edebileceğinden de yardımcı olabilir.

6. Kabul etme oranını yarıya çıkarabileceğinden, tüm makinelerde kontratın devre dışı bırakıldığını bir kez daha kontrol edin (deubeulyou tarafından önerilir). Evet, tüm testlerde devre dışı bırakıldı.

7. "Kuyruk taşmasını dinle ve netstat -s içinde kova taşmasını eşitle" seçeneğini işaretleyin (HN üzerindeki mike_esspe tarafından önerilir).

8. Kesinti işlemeyi birden çok çekirdek arasında bölün (daha önce etkinleştirmeye çalıştığım RPS / RFS bunu yapması gerekiyor, ancak tekrar denemeye değer olabilir). HN de adamt tarafından önerildi.

9. TCP bölümlemenin boşaltılması ve Matt Bailey tarafından önerildiği şekilde hızlanma toplanması / dağılması. (EC2 veya benzeri VPS ana bilgisayarlarında mümkün değildir)

Ayrıca, NIC donanım ivmesini kapatmanın Xen denetleyicisindeki ağ performansını büyük ölçüde geliştirdiğini buldum (LXC için de geçerli):

Scatter-toplamak accell:

/usr/sbin/ethtool -K br0 sg off

TCP bölümlendirme boşaltması:

/usr/sbin/ethtool -K br0 tso off

Br0, hiper yönetici ana bilgisayarındaki köprünüz veya ağ cihazınızdır. Bunu her açılışta kapatmak için ayarlamanız gerekecek. YMMV.

Belki biraz netleştirebilirsiniz - Xen altındaki testleri kendi sunucunuzda mı, yoksa sadece bir EC2 örneğinde mi yaptınız?

Kabul et sadece başka bir sistemdir ve yeni bağlantılar sadece ilk birkaç paketin belirli 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 şunları yapabilir: örneğin EC2'de, Güvenlik Gruplarının bununla bir ilgisi varsa şaşırmam; aynı zamanda yeni bağlantıların kabul edilme oranını yarı yarıya düşürdüğü bildirildi (PDF) .

Son olarak, son zamanlarda Librato tarafından yazıldığı gibi EC2'de (ve muhtemelen genel olarak Xen'de ) garip CPU kullanımına / kilitlenmelerine neden olan CPU / Çekirdek kombinasyonları var gibi görünüyor .

Dom0'daki köprü kodunda iptables ve diğer kancaları devre dışı bıraktığınızdan emin olun. Açıkçası, yalnızca köprü ağları Xen kurulumuna uygulanır.

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 büyüklüğüne bağlıdır ancak daha küçük olanlara (4 çekirdekli işlemci) bir işlemci çekirdeğini Xen dom0'a tahsis eder ve kilitler. Hiper yönetici önyükleme seçenekleri:

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

Fiziksel ethernet PCI cihazını domU’ye geçirmeyi denediniz mi? İyi performans artışı olmalı.