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.
- Bu nasıl Xen altında bu kadar kötü?
- Yeni TCP bağlantıları için performansı geliştirmek için Xen'i ayarlayabilir misiniz?
- 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?
- Xen'in bu gerçekten beklenen bir davranışı mı?
- Yeni TCP bağlantıları için performansı geliştirmek için Xen'i ayarlayabilir misiniz?
- 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?
- Sunucu, çıplak metal donanım üzerinde test edilmiştir ve neredeyse tüm çekirdeği doyurmaktadır.
- 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ı)