tcpdump meningkatkan kinerja udp


13

Saya sedang menjalankan serangkaian tes beban untuk menentukan kinerja pengaturan berikut:

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

Singkatnya, test suite node.js mengirimkan sejumlah metrik setiap x detik ke instance StatsD yang terletak di server lain. StatsD kemudian memilah metrik setiap detik ke instance Graphite yang terletak di server yang sama. Saya kemudian melihat berapa banyak metrik yang sebenarnya dikirim oleh test suite dan berapa banyak yang diterima oleh Graphite untuk menentukan paket loss antara test suite dan Graphite.

Namun saya perhatikan bahwa saya kadang-kadang mendapat tingkat penurunan paket yang sangat besar (perhatikan bahwa itu dikirim dengan protokol UDP), berkisar antara 20-50%. Jadi saat itulah saya mulai mencari di mana paket-paket ini dijatuhkan, mengingat itu bisa menjadi masalah kinerja dengan StatsD. Jadi saya mulai mencatat metrik di setiap bagian sistem untuk melacak di mana penurunan ini terjadi. Dan di sinilah segalanya menjadi aneh.

Saya menggunakan tcpdump untuk membuat file tangkap yang saya periksa setelah tes selesai berjalan. Tetapi setiap kali saya menjalankan tes dengan tcpdump berjalan, paket loss hampir tidak ada! Sepertinya tcpdump entah bagaimana meningkatkan kinerja tes saya dan saya tidak tahu mengapa dan bagaimana melakukan ini. Saya menjalankan perintah berikut untuk mencatat pesan tcpdump di server dan klien:

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

Dalam satu kasus uji tertentu saya mengirim 40000 metrik / s. Tes saat menjalankan tcpdump memiliki paket loss sekitar 4% sedangkan yang tanpa paket loss sekitar 20%

Kedua sistem berjalan sebagai Xen VM dengan pengaturan berikut:

  • Intel Xeon E5-2630 v2 @ 2.60GHz
  • RAM 2GB
  • Ubuntu 14,04 x86_64

Hal-hal yang sudah saya periksa untuk kemungkinan penyebab:

  • Meningkatkan buffer UDP menerima / mengirim ukuran.
  • Beban CPU mempengaruhi tes. (maks. pemuatan 40-50%, baik sisi klien dan server)
  • Menjalankan tcpdump pada antarmuka khusus alih-alih 'apa pun'.
  • Menjalankan tcpdump dengan '-p' untuk menonaktifkan mode promiscuous.
  • Menjalankan tcpdump hanya di server. Hal ini mengakibatkan hilangnya paket sebesar 20% yang terjadi dan tampaknya tidak mempengaruhi tes.
  • Menjalankan tcpdump hanya pada klien. Ini mengakibatkan peningkatan kinerja.
  • Meningkatkan netdev_max_backlog dan netdev_budget menjadi 2 ^ 32-1. Ini tidak membuat perbedaan.
  • Mencoba setiap kemungkinan pengaturan mode promiscuous pada setiap nic (server on dan client off, server off dan client on, keduanya on, keduanya off). Ini tidak membuat perbedaan.

3
Satu hal yang dilakukan tcpdump secara default adalah menempatkan antarmuka jaringan Anda ke mode promiscuous. Anda mungkin ingin melewatkan -popsi untuk melewati melakukan itu untuk melihat apakah itu membuat perbedaan.
Zoredache

Jadi Anda menjalankan tcpdump pada klien dan di server, dan tingkat kehilangan paket turun? Apa yang terjadi jika Anda menjalankannya hanya di klien, dan apa yang terjadi jika Anda hanya menjalankannya di server? (Dan, ya, coba juga mematikan mode promiscuous, dan mungkin juga mencoba menangkap pada antarmuka jaringan tertentu yang digunakan untuk pengujian daripada perangkat "apa pun", untuk melihat apakah itu membuat perbedaan.)

Terima kasih atas komentar anda Saya mencoba kedua rekomendasi Anda dan mengedit pertanyaan saya untuk mencerminkan apa yang saya coba, tetapi ini tidak mempengaruhi masalah.
Ruben Homs

Apakah menempatkan nics pada kedua mesin ke mode promiscuous memiliki efek yang sama dengan menjalankan tcpdump? ifconfig eth0 promiscmengaktifkan dan ifconfig eth0 -promiscmenonaktifkan mode promiscuous pada eth0. Jika ada perbedaan, coba bandingkan 4 kemungkinan kombinasi promisc on / off pada kedua mesin. Itu mungkin membantu menunjukkan dengan tepat sumber masalahnya.
Fox

@Fox Terima kasih atas jawabannya! Saya mencoba semua kombinasi yang mungkin untuk semua nic, tetapi tanpa perbedaan hasil. Saya memperbarui pertanyaan saya untuk mencerminkan hal ini.
Ruben Homs

Jawaban:


10

Ketika tcpdump sedang berjalan, ia akan cukup cepat membaca di frame yang masuk. Hipotesis saya adalah bahwa pengaturan buffer cincin paket NIC mungkin sedikit pada ukuran kecil; ketika tcpdump dijalankan, semakin dikosongkan pada waktu yang lebih tepat.

Jika Anda adalah pelanggan Red Hat, maka artikel dukungan ini sangat berguna Ikhtisar Penerimaan Paket . Ada beberapa hal di sana yang saya pikir belum Anda pertimbangkan.

Pertimbangkan bagaimana sistem Anda berurusan dengan IRQ; pertimbangkan untuk meningkatkan 'dev_weight' antarmuka jaringan (artinya lebih banyak paket yang dibaca dari NIC ke ruang pengguna); lihat seberapa sering aplikasi membaca soket (apakah bisa menggunakan utas khusus, apakah ada masalah / solusi yang diketahui tentang skalabilitas).

Tingkatkan buffer frame NIC (menggunakan ethtoolperintah - lihat --set-ringargumen dll.)

Lihatlah 'terima skala sisi' dan gunakan setidaknya banyak yang menerima utas untuk membaca lalu lintas.

Saya ingin tahu apakah tcpdump melakukan sesuatu yang keren seperti menggunakan dukungan kernel untuk buffer paket cincin . Itu akan membantu menjelaskan perilaku yang Anda lihat.


Karena ini adalah lingkungan Xen, Anda mungkin harus melakukan (setidaknya sebagian) pada host Xen.
Cameron Kerr

Ini adalah sesuatu yang tidak pernah saya pikirkan sebelumnya, hal yang sangat menarik, terima kasih! Saya akan mencoba ini setelah saya mendapatkan akses ke host Xen dan akan memberi tahu Anda bagaimana hasilnya.
Ruben Homs

2

Gubernur kekuasaan apa yang Anda gunakan? Saya telah melihat perilaku serupa dengan gubernur "ondemand" atau "konservatif".

Coba gunakan gubernur "kinerja" dan untuk menonaktifkan semua fitur hemat daya di BIOS server.

Apakah itu mengubah sesuatu?


Saya mengalami kesulitan mencari tahu gubernur kekuasaan apa yang saya gunakan. Saya mencoba menjalankan cpufreq-infotetapi mendapatkan pesan yang mengatakan no or unknown cpufreq driver is active on this CPU. Juga saat menggunakannya cpupower frequency-infokembali no or unknown cpufreq driver is active on this CPU. Meskipun saya tidak dapat mengkonfirmasi ini saat ini, situs web produsen VM membuat saya percaya itu berjalan pada mode "kinerja" karena saya memiliki intel cpu ..
Ruben Homs

Bisakah Anda menunjukkan output dari perintah berikut? 1) cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor2) cat /proc/cpuinfo3)lsmod | grep cpu
shodanshok


1

Cara lain adalah ip_conntarckmodul, Apakah Anda yakin linux-box Anda dapat menerima koneksi baru? tes melalui:

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

Anda harus menguji

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

jika max == count, koneksi maksimum Anda penuh dan linux-box Anda tidak dapat menerima koneksi baru
Jika Anda tidak memiliki ip_conntrack, Anda dapat memuat dengan mudah melaluimodprobe ip_conntrack


2
Dan jika ini masalahnya, maka Anda harus melihat target NOTRACK di tabel 'mentah' untuk mencegah pelacakan koneksi untuk itu. Saya melakukan itu baru-baru ini untuk server DNS yang sibuk dan menghapus iptables dari menjadi hambatan dan menyebabkan batas waktu resolusi DNS.
Cameron Kerr

Dan di sini adalah contoh bagaimana saya menggunakan aturan NOTRACK agar IPTable tidak melakukan pelacakan koneksi untuk DNS UDP. distracted-it.blogspot.co.nz/2015/05/…
Cameron Kerr

1

Saya menduga pihak penerima tidak mampu menangani kecepatan paket dan inilah alasannya:

  1. menggunakan tcpdump pada klien mengurangi paket yang dijatuhkan: tcpdump memperlambat klien dan karenanya server melihat tingkat pengepak yang jauh lebih rendah yang masih dapat ditangani sebagian. Anda harus dapat mengonfirmasi hipotesis ini dengan memeriksa penghitung paket RX / TX di klien dan server

  2. Anda menyebutkan bahwa Anda meningkatkan ukuran terima / kirim buffer UDP, dapatkah Anda merinci caranya? Penting bahwa pada server Anda mengubah rmem_max dan rmem_default, contoh: 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

Menguji pengaturan Anda

Hentikan statsd dan aplikasi node, kemudian dengan sistem idle gunakan iperf untuk menguji kecepatan paket yang dapat ditangani oleh jaringan / kernel. Jika Anda dapat melakukan streaming paket 40K / s dengan iperf tetapi tidak bisa dengan statsd maka Anda harus memusatkan upaya Anda pada tuning statsd.

Merdu lainnya

Juga ingat untuk menyetel net.core.netdev_max_backlog : jumlah paket maksimum yang diizinkan untuk mengantri ketika antarmuka tertentu menerima paket lebih cepat daripada yang dapat diproses oleh kernel.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.