tcpdump udp performansını artırır

Aşağıdaki kurulumun performansını belirlemek için bir dizi yük testi çalıştırıyorum:

Node.js test suite (client) --> StatsD (server) --> Graphite (server)

Kısacası, node.js test paketi, başka bir sunucuda bulunan bir StatsD örneğine her x saniyede bir belirli miktarda metrik gönderir. Daha sonra StatsD, metrikleri her saniye aynı sunucuda bulunan bir Grafit örneğine temizler. Daha sonra test takımı tarafından kaç metrikin gönderildiğine ve test takımı ve Grafit arasındaki paket kaybını belirlemek için Grafit tarafından kaç metrenin alındığına bakarım.

Bununla birlikte, bazen% 20-50 arasında değişen çok büyük paket düşüş oranları aldığımı fark ettim (UDP protokolü ile gönderildiğini unutmayın). İşte o zaman bu paketlerin nereye bırakıldığını araştırmaya başladım ve StatsD ile ilgili bir performans sorunu olabileceğini gördüm. Bu yüzden, bu düşüşün nerede gerçekleştiğini izlemek için sistemin her bölümündeki metrikleri günlüğe kaydetmeye başladım. Ve işlerin garipleştiği yer burası.

Test çalıştıktan sonra incelemek bir yakalama dosyası oluşturmak için tcpdump kullanıyorum . Ancak tcpdump çalışırken testleri her çalıştırdığımda, paket kaybı neredeyse yok! Görünüşe göre tcpdump testlerimin performansını bir şekilde artırıyor ve bunu neden ve nasıl yaptığını anlayamıyorum. Hem sunucuda hem de istemcide tcpdump iletilerini günlüğe kaydetmek için aşağıdaki komutu çalıştırıyorum:

tcpdump -i any -n port 8125 -w test.cap

Belirli bir test durumunda 40000 metrik / saniye gönderiyorum. Tcpdump çalıştırılırken yapılan testin paket kaybı yaklaşık% 4 iken, olmayan paketin kaybı yaklaşık% 20'dir.

Her iki sistem de aşağıdaki kurulumla Xen VM'leri olarak çalışıyor:

• Intel Xeon E5-2630 v2 @ 2.60GHz
• 2GB RAM
• Ubuntu 14.04 x86_64

Olası nedenler için zaten kontrol ettiğim şeyler:

• UDP arabellek alma / gönderme boyutunu artırma.
• Testi etkileyen CPU yükü. (maksimum yük% 40-50, hem istemci hem de sunucu tarafı)
• 'Any' yerine belirli arayüzlerde tcpdump çalıştırılıyor.
• Karışık modu devre dışı bırakmak için '-p' ile tcpdump çalıştırılıyor.
• TCpdump yalnızca sunucuda çalıştırılıyor. Bu% 20'lik paket kaybıyla sonuçlandı ve testleri etkilemediği görülüyor.
• Tcpdump yalnızca istemcide çalıştırılıyor. Bu, performansın artmasına neden oldu.
• Netdev_max_backlog ve netdev_budget değerinin 2 ^ 32-1 değerine yükseltilmesi. Bu bir fark yaratmadı.
• Her nic üzerinde olası her mod ayarını denedim (sunucu açık ve istemci kapalı, sunucu kapalı ve istemci açık, her ikisi de açık, her ikisi de kapalı). Bu bir fark yaratmadı.

Tcpdump çalışırken, gelen karelerde okuma oldukça istenecektir. Benim hipotezim, NIC'nin paket halka arabellek ayarlarının küçük boyutta biraz olabileceğidir; tcpdump çalışırken daha zamanında boşaltılır.

Red Hat abonesiyseniz, bu destek makalesi çok yararlıdır Paket Alımına Genel Bakış . İçinde henüz düşündüğünü düşünmediğim bazı şeyler var.

Sisteminizin IRQ'larla nasıl başa çıktığını düşünün; ağ arabiriminin 'dev_weight' değerini artırmayı düşünün (NIC'den kullanıcı alanına daha fazla paket okunur); uygulamanın soketi ne sıklıkta okuduğuna bakın (özel bir iş parçacığı kullanabilir mi, ölçeklenebilirlikle ilgili bilinen sorunlar / geçici çözümler var mı).

NIC çerçeve arabelleğini artırın ( ethtoolkomutu kullanarak - --set-ringvs. bağımsız değişkenlerine bakın).

'Yan ölçeklendirmeyi al' bölümüne bakın ve trafikte okumak için en azından bu alıcı dizisini kullanın.

Tcpdump'ın paket halka tamponları için çekirdek desteğini kullanmak gibi harika bir şey yapıp yapmadığını merak ediyorum . Bu, gördüğünüz davranışı açıklamaya yardımcı olur.

Hangi güç valisini kullanıyorsunuz? "Ondemand" veya "muhafazakar" vali ile benzer davranışlar gördüm.

"Performans" düzenleyicisini kullanmayı ve sunucu BIOS'undaki güç tasarrufu özelliklerini devre dışı bırakmayı deneyin.

Bir şey değiştiriyor mu?

Başka bir yol ip_conntarckmodülü, Linux kutunuzun yeni bağlantı kabul edebileceğinden emin misiniz? üzerinden test:

root@debian:/home/mohsen# sysctl net.ipv4.netfilter.ip_conntrack_max
net.ipv4.netfilter.ip_conntrack_max = 65536
root@debian:/home/mohsen# sysctl  net.ipv4.netfilter.ip_conntrack_count
net.ipv4.netfilter.ip_conntrack_count = 29

Test etmek zorundasın

net.ipv4.netfilter.ip_conntrack_max >  net.ipv4.netfilter.ip_conntrack_count

max == sayılırsa, maksimum bağlantınız doludur ve linux kutunuz yeni bağlantıyı kabul edemez.
İp_conntrack'ınız yoksa kolayca yükleyebilirsiniz.modprobe ip_conntrack

Alıcı tarafın sadece paket hızını idare edemediğinden şüpheleniyorum ve işte nedeni:

1. istemcide tcpdump kullanılması bırakılan paketleri azaltır: tcpdump istemciyi yavaşlatır ve bu nedenle sunucu hala kısmen işleyebileceği çok daha düşük bir paketleyici hızı görmektedir. Hem istemci hem de sunucudaki RX / TX paket sayaçlarını kontrol ederek bu hipotezi onaylayabilmeniz gerekir

2. UDP arabellek alma / gönderme boyutunu artırdığınızı belirttiniz, nasıl detaylandırırsınız? Sunucu üzerinde size rmem_max hem değiştirmemiz önemlidir ve rmem_default, örnek: sysctl -w net.core.rmem_max=524287 sysctl -w net.core.wmem_max=524287 sysctl -w net.core.rmem_default=524287 sysctl -w net.core.wmem_default=524287

Ayarlarınızı test etme

Statisticsd ve düğüm uygulamasını durdurun, ardından sistem boşta iken ağ / çekirdeğin işleyebileceği paket hızını test etmek için iperf kullanın. İperf ile 40 bin paket / s yayınlayabilir, ancak istatistik ile yayınlayamıyorsanız, çabalarınızı istatistik ayarlamaya odaklamalısınız.

Diğer ayarlanabilir malzemeler

Ayrıca net.core.netdev_max_backlog dosyasını ayarlamayı unutmayın : belirli bir arabirim çekirdeğin bunları işleyebileceğinden daha hızlı paketleri aldığında sıraya girmesine izin verilen maksimum paket sayısı.