Berapa banyak jaringan yang memerlukan NIC polling vs interupsi?

18

Apakah ada yang punya beberapa data atau perhitungan dasar yang bisa menjawab ketika frame coalescing (NAPI) diperlukan dan ketika satu interupsi per frame sudah cukup?

Perangkat keras saya: IBM BladeServer HS22, Broadcom 5709 perangkat keras NIC Gigabit (MSI-X), dengan prosesor quad-core Xeon E5530 dual Xeon. Tujuan utama adalah server proxy Squid. Switch adalah seri Cisco 6500 yang bagus.

Masalah dasar kami adalah bahwa selama masa sibuk (lalu lintas 100 Mbps, hanya 10.000 pps) latensi dan paket loss meningkat. Saya telah melakukan banyak tuning dan upgrade kernel ke 2.6.38 dan telah meningkatkan paket loss tetapi latency masih buruk. Ping bersifat sporadis; melompat bahkan hingga 200 ms pada LAN Gbps lokal. Respons rata-rata squid melonjak dari 30 ms menjadi 500+ ms meskipun beban CPU / memori baik-baik saja.

Interupsi naik menjadi sekitar 15.000 / detik selama puncak. Ksoftirqd tidak menggunakan banyak CPU; Saya telah menginstal irqbalance untuk menyeimbangkan IRQ (masing-masing 8 untuk eth0 dan eth1) di semua core tetapi itu tidak banyak membantu.

Intel NIC sepertinya tidak pernah memiliki masalah seperti ini, tetapi lakukan fakta dari sistem blades dan perangkat konfigurasi tetap, kami agak terjebak dengan Broadcoms.

Semuanya menunjuk pada NIC sebagai penyebab utama. Ide terbaik yang saya miliki saat ini adalah mencoba mengurangi interupsi sekaligus menjaga latensi rendah dan throughput tetap tinggi.

Sayangnya bnx2 tidak mendukung adaptif-rx atau tx.

Jawaban utas NAPI vs Adaptive Interrupts memberikan pandangan yang baik atas moderasi interupsi tetapi tidak ada informasi konkret tentang cara menghitung pengaturan gabungan ethtool yang optimal untuk solusi yang diberikan. Apakah ada pendekatan yang lebih baik daripada hanya coba-coba?

Apakah beban kerja dan konfigurasi perangkat keras yang disebutkan di atas bahkan perlu NAPI? Atau haruskah bisa hidup dengan interupsi tunggal per paket?

Wim Kerkhoff
sumber
Pasti pertanyaan yang sulit ... Terima kasih untuk hadiahnya, @Holocryptic! Saya telah mencoba beberapa pengaturan "ethtool -c" untuk penggabungan tetapi belum ada perbedaan yang luar biasa.
Wim Kerkhoff
Tidak masalah. Saya hanya melihatnya agak lama di sana selama beberapa hari dan sepertinya pertanyaan yang bagus. Semoga seseorang memiliki sesuatu untuk Anda.
Holocryptic
Pembaruan lain ... kami telah pindah ke bilah IBM HS23 dengan NICs Emulex 10 Gbps. Minggu ini kami mencapai lebih dari 800.000 paket / detik, tanpa tetes. Kami harus melakukan banyak penyetelan (menambal driver kernel Linux) untuk mendapatkan keseimbangan IRQs tetapi bekerja dengan baik sekarang.
Wim Kerkhoff

Jawaban:

6

Pertanyaan bagus yang membuat saya membaca untuk mencoba dan mencari tahu. Seandainya saya bisa mengatakan saya punya jawaban ... tapi mungkin beberapa petunjuk.

Setidaknya saya bisa menjawab pertanyaan Anda, "seandainya itu bisa hidup dengan interupsi tunggal per paket". Saya pikir jawabannya adalah ya, berdasarkan firewall yang sangat sibuk yang dapat saya akses:

Output Sar:

03:04:53 PM     IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s   txcmp/s  rxmcst/s
03:04:54 PM        lo     93.00     93.00      6.12      6.12      0.00      0.00      0.00
03:04:54 PM      eth0 115263.00 134750.00  13280.63  41633.46      0.00      0.00      5.00
03:04:54 PM      eth8  70329.00  55480.00  20132.62   6314.51      0.00      0.00      0.00
03:04:54 PM      eth9  53907.00  66669.00   5820.42  21123.55      0.00      0.00      0.00
03:04:54 PM     eth10      0.00      0.00      0.00      0.00      0.00      0.00      0.00
03:04:54 PM     eth11      0.00      0.00      0.00      0.00      0.00      0.00      0.00
03:04:54 PM      eth1      0.00      0.00      0.00      0.00      0.00      0.00      0.00
03:04:54 PM      eth2 146520.00 111904.00  45228.32  12251.48      0.00      0.00     10.00
03:04:54 PM      eth3    252.00  23446.00     21.34   4667.20      0.00      0.00      0.00
03:04:54 PM      eth4      8.00     10.00      0.68      0.76      0.00      0.00      0.00
03:04:54 PM      eth5      0.00      0.00      0.00      0.00      0.00      0.00      0.00
03:04:54 PM      eth6   3929.00   2088.00   1368.01    183.79      0.00      0.00      1.00
03:04:54 PM      eth7     13.00     17.00      1.42      1.19      0.00      0.00      0.00
03:04:54 PM     bond0 169170.00 201419.00  19101.04  62757.00      0.00      0.00      5.00
03:04:54 PM     bond1 216849.00 167384.00  65360.94  18565.99      0.00      0.00     10.00

Seperti yang Anda lihat, beberapa paket per detik sangat tinggi, dan tidak ada penyesuaian ethtool khusus yang dilakukan pada mesin ini. Oh ... chipset Intel. : \

Satu-satunya hal yang dilakukan adalah beberapa penyeimbangan irq manual dengan / proc / irq / XXX / smp_affinity, berdasarkan per-antarmuka. Saya tidak yakin mengapa mereka memilih untuk pergi ke sana daripada dengan irqbalance, tetapi tampaknya berhasil.

Saya juga memikirkan matematika yang diperlukan untuk menjawab pertanyaan Anda, tetapi saya pikir ada terlalu banyak variabel. Jadi ... untuk meringkas, menurut pendapat saya, jawabannya adalah tidak, saya tidak berpikir Anda dapat memprediksi hasilnya di sini, tetapi dengan pengambilan data yang cukup Anda harus dapat mengubahnya ke tingkat yang lebih baik.

Setelah mengatakan semua itu, firasat saya adalah bahwa Anda entah bagaimana terikat dengan perangkat keras di sini ... seperti pada firmware atau bug interop dari beberapa jenis.

DictatorBob
sumber
Beberapa latar belakang yang bermanfaat di sini: alexonlinux.com/…
DictatorBob
1
Saya setuju dengan pernyataan dasar "ya, seharusnya tidak memiliki masalah", tetapi melihat bagaimana mereka memiliki masalah itu kemungkinan masalah firmware atau driver. Saya belum "menyetel" workstation saya sama sekali dan dapat menarik 65kips tanpa berkeringat; 15kips seharusnya bukan apa-apa untuk CPU modern. Saya menggunakan Broadcom NIC secara eksklusif, 5709 menjadi yang paling umum sejauh ini. Namun tes ini dijalankan pada FreeBSD, bukan Linux.
Chris S
Terima kasih atas idenya. Saya memang mencoba irqbalance tetapi tidak melihat perbedaan. Saya bermain dengan pengaturan yang lebih menyatu (ethtool -c) tetapi tidak melihat perbedaan. Salah satu bilah sebenarnya adalah penyeimbang beban, mendorong hingga 120.000 paket / detik. Saya perhatikan bahwa jika NAT dan conntrack iptables dimuat, penggunaan CPU ksoftirqd menjadi 100%. Bongkar modul-modul itu dan muat turun ke 0. Di server Squid (maks 10.000 paket / detik), saya menghapus 17.000 (!!!) aturan iptables dan segera latensi turun. Saya pikir saya sudah mencobanya sebelumnya, tetapi ternyata tidak ...
Wim Kerkhoff
3

Tentu saja mengingat kemampuan CPU, chipset, dan bus dibandingkan dengan jumlah lalu lintas yang rendah seperti yang Anda miliki, tidak ada alasan apa pun bagi Anda untuk MEMBUTUHKAN segala bentuk manajemen interupsi. Kami memiliki beberapa mesin RHEL 5.3 64-bit dengan NIC 10Gbps dan interupsi mereka tidak terlalu buruk sama sekali, ini 100 kali lebih sedikit.

Tentunya Anda memiliki konfigurasi tetap (saya menggunakan pisau HP yang sangat mirip) jadi mengganti NIC untuk Intels sekarang merupakan pilihan yang mudah, tetapi apa yang akan saya katakan adalah bahwa saya mulai menemukan sejumlah masalah serupa di forum ini dan di tempat lain dengan Broadcom NIC tertentu. Pernah situs SE sendiri memiliki beberapa masalah dengan inkonsistensi semacam ini dan bertukar dengan Intel NIC benar-benar membantu.

Apa yang saya sarankan adalah memilih satu bilah dan menambahkan adaptor berbasis Intel ke satu mesin itu, Anda jelas harus menambahkan interkoneksi atau apa pun yang IBM panggil untuk mengeluarkan sinyal tetapi coba setup perangkat lunak yang sama tetapi dengan yang lain ini. NIC (mungkin menonaktifkan Broadcom jika Anda bisa). Uji ini dan lihat bagaimana Anda melanjutkan, saya tahu apa yang saya jelaskan memerlukan beberapa perangkat keras tambahan, tetapi saya bayangkan perwakilan IBM Anda akan dengan senang hati meminjamkannya kepada Anda. Itu satu-satunya cara untuk mengetahui dengan pasti. Harap beri tahu kami apa yang Anda ketahui, saya benar-benar tertarik jika ada masalah dengan NIC ini, bahkan jika itu kasus tepi yang aneh. Sebagai tambahan saya akan bertemu dengan Intel dan Broadcom minggu depan untuk membahas sesuatu yang sama sekali tidak terkait tetapi saya pasti akan membahasnya dengan mereka dan memberi tahu Anda jika saya menemukan sesuatu yang menarik.

Chopper3
sumber
1

Pertanyaan tentang interupsi adalah bagaimana mereka mempengaruhi kinerja sistem secara keseluruhan. Interupsi dapat mencegah pemrosesan lahan oleh pengguna dan kernel dan meskipun Anda mungkin tidak melihat banyak penggunaan CPU, ada banyak pergantian konteks yang terjadi dan itu adalah kinerja yang luar biasa. Anda dapat menggunakan vmstatdan memeriksa systemkolom, cstajuk untuk interupsi dan sakelar konteks per detik (interupsi menyertakan jam sehingga Anda harus mempertimbangkannya), nilainya juga untuk cek.

coredump
sumber
1

Jawaban langsung singkatnya:

Jika Anda mengaktifkan jajak pendapat, Anda akan mengurangi sakelar konteks (biasanya karena interupsi) dari apa pun sekarang (15kips dalam kasus Anda) ke nomor yang telah ditentukan (biasanya 1k ke 2k).

Jika saat ini Anda memiliki lalu lintas di atas angka yang telah ditentukan maka Anda harus memiliki waktu respons yang lebih baik dengan mengaktifkan polling. Kebalikannya juga benar. Saya tidak akan mengatakan ini "perlu" kecuali jika konteksnya mempengaruhi kinerja.

Chris S
sumber
1

Untuk tindak lanjut: dengan NAT dan modul-modul penghubung dibongkar ditambah aturan iptables yang diperkecil, kami mendapatkan kinerja yang luar biasa. Load balancer IPVS telah melakukan lebih dari 900 Mbps / 150 kpps. Ini sementara masih menggunakan chipset Broadcom bnx2 yang sama.

Jadi untuk menyimpulkan: penanganan interupsi tampaknya baik dan default untuk Debian dengan kernel 2.6.38 / 3.0.x tampaknya bekerja dengan baik.

Jelas saya lebih suka menggunakan Intel NIC sehingga kita dapat menggunakan paket standar Debian. Memerangi firmware bnx2 yang tidak bebas telah membuang banyak waktu.

Wim Kerkhoff
sumber
Hanya pembaruan lainnya. Baru-baru ini kinerjanya menurun lagi tanpa alasan yang jelas. Kami meninjau semua optimasi sebelumnya tanpa hasil. Intel NIC masih bukan pilihan ekonomis (investasi $ 30- $ 40.000 untuk interkoneksi baru, sakelar 10GB, dll.). NAMUN, kami menemukan beberapa bilah IBM HS22 yang sedikit lebih baru yang masih menggunakan bnx2 jelek, tetapi dengan firmware yang lebih baru. Performanya jauh lebih baik - kami menembus 150.000 paket / penghalang detik.
Wim Kerkhoff