CPU0 dibanjiri dengan interupsi eth1

Saya memiliki VM Ubuntu, berjalan di dalam Xen XCP berbasis Ubuntu. Itu host layanan HTTP berbasis FCGI kustom, di belakang nginx.

Di bawah beban dari ab inti CPU pertama jenuh, dan sisanya di bawah-dimuat.

Dalam /proc/interruptssaya melihat bahwa CPU0 melayani urutan besarnya lebih banyak interupsi daripada inti lainnya. Kebanyakan dari mereka berasal eth1.

Apakah ada yang bisa saya lakukan untuk meningkatkan kinerja VM ini? Apakah ada cara untuk menyeimbangkan interupsi lebih merata?

Detail berdarah:

$ uname -a
Linux MYHOST 2.6.38-15-virtual # 59-Ubuntu SMP Jumat 27 Apr 16:40:18 UTC 2012 i686 i686 i386 GNU / Linux

$ lsb_release -a
Tidak ada modul LSB yang tersedia.
ID Distributor: Ubuntu
Deskripsi: Ubuntu 11.04
Rilis: 11,04
Nama kode: rapi

$ cat / proc / interupsi 
           CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7       
283: 113720624 0 0 0 0 0 0 0 xen-dyn-event eth1
284: 1 0 0 0 0 0 0 0 xen-dyn-event eth0
285: 2254 0 0 3873799 0 0 0 0 xen-dyn-event blkif
286: 23 0 0 0 0 0 0 0 xen-dyn-event hvc_console
287: 492 42 0 0 0 0 0 295324 xen-dyn-event xenbus
288: 0 0 0 0 0 0 0 222294 xen-percpu-ipi callfuncsingle7
289: 0 0 0 0 0 0 0 0 xen-percpu-virq debug7
290: 0 0 0 0 0 0 0 151302 xen-percpu-ipi callfunc7
291: 0 0 0 0 0 0 0 3236015 xen-percpu-ipi resched7
292: 0 0 0 0 0 0 0 60064 xen-percpu-ipi spinlock7
293: 0 0 0 0 0 0 0 12355510 xen-percpu-virq timer7
294: 0 0 0 0 0 0 803174 0 xen-percpu-ipi callfuncsingle6
295: 0 0 0 0 0 0 0 0 xen-percpu-virq debug6
296: 0 0 0 0 0 0 60027 0 xen-percpu-ipi callfunc6
297: 0 0 0 0 0 0 5374762 0 xen-percpu-ipi resched6
298: 0 0 0 0 0 0 64976 0 xen-percpu-ipi spinlock6
299: 0 0 0 0 0 0 15294870 0 timer xen-percpu-virq6
300: 0 0 0 0 0 264441 0 0 xen-percpu-ipi callfuncsingle5
301: 0 0 0 0 0 0 0 0 xen-percpu-virq debug5
302: 0 0 0 0 0 79324 0 0 xen-percpu-ipi callfunc5
303: 0 0 0 0 0 3468144 0 0 xen-percpu-ipi resched5
304: 0 0 0 0 0 66269 0 0 xen-percpu-ipi spinlock5
305: 0 0 0 0 0 12778464 0 0 timer xen-percpu-virq5
306: 0 0 0 0 844591 0 0 0 xen-percpu-ipi callfuncsingle4
307: 0 0 0 0 0 0 0 0 xen-percpu-virq debug4
308: 0 0 0 0 75293 0 0 0 xen-percpu-ipi callfunc4
309: 0 0 0 0 3482146 0 0 0 xen-percpu-ipi resched4
310: 0 0 0 0 79312 0 0 0 xen-percpu-ipi spinlock4
311: 0 0 0 0 21642424 0 0 0 timer xen-percpu-virq4
312: 0 0 0 449141 0 0 0 0 xen-percpu-ipi callfuncsingle3
313: 0 0 0 0 0 0 0 0 xen-percpu-virq debug3
314: 0 0 0 95405 0 0 0 0 xen-percpu-ipi callfunc3
315: 0 0 0 3802992 0 0 0 0 xen-percpu-ipi resched3
316: 0 0 0 76607 0 0 0 0 xen-percpu-ipi spinlock3
317: 0 0 0 16439729 0 0 0 0 xen-percpu-virq timer3
318: 0 0 876383 0 0 0 0 0 xen-percpu-ipi callfuncsingle2
319: 0 0 0 0 0 0 0 0 xen-percpu-virq debug2
320: 0 0 76416 0 0 0 0 0 xen-percpu-ipi callfunc2
321: 0 0 3422476 0 0 0 0 0 xen-percpu-ipi resched2
322: 0 0 69217 0 0 0 0 0 xen-percpu-ipi spinlock2
323: 0 0 10247182 0 0 0 0 0 timer xen-percpu-virq2
324: 0 393514 0 0 0 0 0 0 xen-percpu-ipi callfuncsingle1
325: 0 0 0 0 0 0 0 0 xen-percpu-virq debug1
326: 0 95773 0 0 0 0 0 0 xen-percpu-ipi callfunc1
327: 0 3551629 0 0 0 0 0 0 xen-percpu-ipi resched1
328: 0 77823 0 0 0 0 0 0 xen-percpu-ipi spinlock1
329: 0 13784021 0 0 0 0 0 0 timer xen-percpu-virq1
330: 730435 0 0 0 0 0 0 0 xen-percpu-ipi callfuncsingle0
331: 0 0 0 0 0 0 0 0 xen-percpu-virq debug0
332: 39649 0 0 0 0 0 0 0 fungsi panggilan xen-percpu-ipi0
333: 3607120 0 0 0 0 0 0 0 xen-percpu-ipi resched0
334: 348740 0 0 0 0 0 0 0 xen-percpu-ipi spinlock0
335: 89912004 0 0 0 0 0 0 0 timer xen-percpu-virq0
NMI: 0 0 0 0 0 0 0 0 Interupsi yang tidak bisa ditutup
LOC: 0 0 0 0 0 0 0 0 Timer lokal menyela
SPU: 0 0 0 0 0 0 0 0 Interupsi palsu
PMI: 0 0 0 0 0 0 0 0 Pemantauan interupsi kinerja
IWI: 0 0 0 0 0 0 0 0 IRQ interupsi kerja
RES: 3607120 3551629 3422476 3802992 3482146 3468144 5374762 3236015 Menjadwalkan ulang interupsi
CAL: 770084 489287 952799 544546 919884 343765 863201 373596 Panggilan fungsi terputus
TLB: 0 0 0 0 0 0 0 0 TLB shootdown
TRM: 0 0 0 0 0 0 0 0 Thermal event interrupts
THR: 0 0 0 0 0 0 0 0 Threshold APIC menyela
MCE: 0 0 0 0 0 0 0 0 Pengecekan periksa mesin
MCP: 0 0 0 0 0 0 0 0 Polling pemeriksaan mesin
ERR: 0
MIS: 0

Lihat di /proc/irq/283direktori. Ada smp_affinity_listfile yang menunjukkan CPU mana yang akan mendapatkan interupsi 283. Bagi Anda file ini mungkin mengandung "0" (dan smp_affinitymungkin berisi "1").

Anda dapat menulis rentang CPU ke smp_affinity_listfile:

echo 0-7 | sudo tee /proc/irq/283/smp_affinity_list

Atau Anda dapat menulis bitmask, di mana setiap bit berhubungan dengan CPU, untuk smp_affinity:

printf %x $((2**8-1)) | sudo tee /proc/irq/283/smp_affinity

Namun, irqbalance diketahui memiliki ide sendiri tentang apa yang harus dimiliki setiap interupsi, dan mungkin mengembalikan pembaruan Anda. Jadi yang terbaik adalah jika Anda hanya menghapus instalansi sepenuhnya. Atau setidaknya hentikan dan matikan agar tidak muncul saat reboot.

Jika tanpa irqbalance Anda menjadi aneh smp_affinitykarena interupsi 283 setelah reboot, Anda harus memperbarui afinitas CPU secara manual di salah satu skrip startup Anda.

Jika Anda memiliki model Intel NIC yang tepat, Anda dapat meningkatkan kinerja secara signifikan.

Mengutip paragraf pertama:

Prosesor multicore dan adapter Ethernet terbaru (termasuk 82575, 82576, 82598, dan 82599) memungkinkan aliran penerusan TCP dioptimalkan dengan menetapkan aliran eksekusi ke masing-masing inti. Secara default, Linux secara otomatis memberikan interupsi ke inti prosesor. Dua metode saat ini ada untuk secara otomatis menetapkan interupsi, penyeimbang IRQ kernel dan daemon keseimbangan IRQ di ruang pengguna. Keduanya menawarkan pengorbanan yang mungkin menurunkan penggunaan CPU tetapi tidak memaksimalkan tingkat penerusan IP. Throughput optimal dapat diperoleh dengan secara manual menyematkan antrian adaptor Ethernet ke inti prosesor tertentu.

Untuk penerusan IP, pasangan antrian pengiriman / penerimaan harus menggunakan inti prosesor yang sama dan mengurangi sinkronisasi cache antara inti yang berbeda. Ini dapat dilakukan dengan menugaskan mengirim dan menerima interupsi ke core tertentu. Dimulai dengan kernel Linux 2.6.27, banyak antrian dapat digunakan pada 82575, 82576, 82598, dan 82599. Selain itu, beberapa antrian transmisi diaktifkan di Extended Messaging Signaled Interrupts (MSI-X). MSI-X mendukung sejumlah besar interupsi yang dapat digunakan, memungkinkan untuk kontrol yang lebih baik dan penargetan interupsi pada CPU tertentu.

Lihat: Menetapkan Interupsi ke Core Prosesor menggunakan Intel® 82575/82576 atau 82598/82599 Ethernet Controller

Sebenarnya sangat disarankan, terutama ketika berhadapan dengan proses berulang dalam waktu singkat, bahwa semua gangguan yang dihasilkan oleh antrian perangkat ditangani oleh CPU yang sama, alih-alih keseimbangan IRQ dan dengan demikian Anda akan melihat kinerja yang lebih baik jika satu CPU menangani interupsi eth1 Pengecualian *** disediakan di bawah ini

Sumber, yang ditautkan di atas, berasal dari Simposium Linux dan saya sarankan Anda membaca beberapa paragraf di SMP IRQ Affinity karena itu akan meyakinkan Anda lebih efektif daripada posting ini.

Mengapa?

Ingat setiap prosesor memiliki cache sendiri selain dapat mengakses memori utama, lihat diagram ini . Ketika sebuah interupsi dipicu, sebuah inti CPU harus mengambil instruksi untuk menangani interupsi dari memori utama, yang membutuhkan waktu lebih lama daripada instruksi di mana dalam cache. Setelah prosesor menjalankan tugas, ia akan memiliki instruksi tersebut dalam cache. Sekarang katakanlah inti CPU yang sama menangani interupsi yang sama hampir sepanjang waktu, fungsi pengendali interupsi tidak akan meninggalkan cache inti CPU, meningkatkan kinerja kernel.

Atau, ketika IRQ seimbang, ia dapat menetapkan gangguan untuk ditangani terus-menerus oleh CPU yang berbeda, maka inti CPU baru mungkin tidak akan memiliki fungsi pengendali interupsi dalam cache, dan waktu yang lama akan diperlukan untuk mendapatkan handler yang tepat dari main Penyimpanan.

Pengecualian : jika Anda jarang menggunakan interupsi eth1, yang berarti cukup waktu berlalu bahwa cache ditimpa dengan melakukan tugas-tugas lain, artinya Anda memiliki data yang datang ke antarmuka itu sebentar-sebentar dengan periode panjang di antara ... maka kemungkinan besar Anda tidak akan melihat manfaat ini karena ketika Anda menggunakan proses pada frekuensi tinggi.

Kesimpulan

Jika interupsi Anda terjadi sangat sering maka ikat saja interupsi tersebut untuk ditangani oleh CPU tertentu saja. Konfigurasi ini hidup di

 /proc/'IRQ number'/smp_affinity

atau

/proc/irq/'IRQ number'/smp_affinity

Lihat paragraf terakhir di bagian SMP IRQ Affinity dari sumber yang ditautkan di atas, ada instruksi.

kalau tidak

Anda dapat mengubah frekuensi flag interupsi dinaikkan dengan meningkatkan ukuran MTU (jumbo frames) jika jaringan memperbolehkannya atau mengubah agar flag dinaikkan setelah jumlah paket yang lebih besar diterima daripada pada setiap paket ATAU mengubah waktu habis, jadi naikkan interupsi setelah waktu tertentu. Perhatian dengan opsi waktu karena ukuran buffer Anda mungkin penuh sebelum waktu habis. Ini dapat dilakukan dengan menggunakan ethtool yang diuraikan dalam sumber tertaut.

jawaban ini mendekati panjang di mana orang tidak akan membacanya jadi saya tidak akan pergi ke banyak detail, tetapi tergantung pada situasi Anda ada banyak solusi ... periksa sumbernya :)