CPU0, eth1 kesintileriyle doludur


12

Ubuntu tabanlı Xen XCP içinde çalışan bir Ubuntu VM'im var. Arkasında özel bir FCGI tabanlı HTTP hizmeti barındırır nginx.

İlk CPU çekirdeğinden gelen yük altında ab doyurulur ve geri kalanı da düşük yüklüdür.

Olarak /proc/interruptsgörmek bu CPU0 başka çekirdek daha büyüklüğü fazla kesme bir sipariş vermektedir. Çoğu geliyor eth1.

Bu sanal makinenin performansını artırmak için yapabileceğim bir şey var mı? Kesmeleri daha dengeli bir şekilde dengelemenin bir yolu var mı?


Kanlı detaylar:

$ uname -a
Linux MYHOST 2.6.38-15-sanal # 59-Ubuntu SMP Cum 27 Nis 16:40:18 UTC 2012 i686 i686 i386 GNU / Linux

$ lsb_release -a
Kullanılabilir LSB modülü yok.
Distribütör Kimliği: Ubuntu
Açıklama: Ubuntu 11.04
Sürüm: 11.04
Kod adı: natty

$ cat / proc / kesmeler 
           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-olayı 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 hata ayıklama7
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 zamanlayıcı7
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 hata ayıklama6
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 xen-percpu-virq zamanlayıcı6
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 hata ayıklama5
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 xen-percpu-virq zamanlayıcı5
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 hata ayıklama4
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 xen-percpu-virq zamanlayıcı4
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 hata ayıklama3
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 zamanlayıcı3
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 hata ayıklama2
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 xen-percpu-virq zamanlayıcı2
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 hata ayıklama1
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 xen-percpu-virq zamanlayıcı1
330: 730435 0 0 0 0 0 0 0 xen-percpu-ipi Instagram Hesabındaki Resim ve Videoları callfuncsingle0
331: 0 0 0 0 0 0 0 0 xen-percpu-virq hata ayıklama0
332: 39649 0 0 0 0 0 0 0 xen-percpu-ipi callfunc0
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 xen-percpu-virq zamanlayıcı0
NMI: 0 0 0 0 0 0 0 0 Maskelenemeyen kesmeler
LOC: 0 0 0 0 0 0 0 0 Yerel zamanlayıcı kesintileri
SPU: 0 0 0 0 0 0 0 0 Sahte kesmeler
PMI: 0 0 0 0 0 0 0 0 Performans izleme kesintileri
IWI: 0 0 0 0 0 0 0 0 IRQ iş kesintileri
RES: 3607120 3551629 3422476 3802992 3482146 3468144 5374762 3236015 Yeniden zamanlama kesintileri
CAL: 770084 489287 952799 544546 919884 343765 863201 373596 İşlev çağrısı kesmeleri
TLB: 0 0 0 0 0 0 0 0 TLB çekimi
TRM: 0 0 0 0 0 0 0 0 Termal olay kesintileri
THR: 0 0 0 0 0 0 0 0 Eşik APIC kesintileri
MCE: 0 0 0 0 0 0 0 0 Makine kontrolü istisnaları
MCP: 0 0 0 0 0 0 0 0 Makine kontrol anketleri
HATA: 0
YBS: 0

Bonus soru: Kesinti sayısını azaltmak için bir yol var eth1mı?
Alexander Gladysh

Yanıtlar:


10

Bak /proc/irq/283dizine. smp_affinity_listHangi CPU'ların 283 kesmesini alacağını gösteren bir dosya var. Senin için bu dosya muhtemelen "0" smp_affinityiçeriyor (ve muhtemelen "1" içeriyor).

CPU aralığını smp_affinity_listdosyaya yazabilirsiniz :

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

Veya her bitin bir CPU'ya karşılık geldiği bir bit maskesi yazabilirsiniz smp_affinity:

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

Bununla birlikte, irqbalance'ın her kesmenin hangi yakınlığa sahip olması gerektiği konusunda kendi fikri olduğu bilinmektedir ve güncellemelerinizi geri alabilir. Bu yüzden irqbalance'ı tamamen kaldırmanız en iyisidir. Ya da en azından durdurun ve yeniden başlatma sırasında gelmesini devre dışı bırakın.

Düzensizlik olmasa bile smp_affinity, yeniden başlatmadan sonra 283 kesme için garip davranıyorsanız , başlangıç ​​komut dosyalarınızdan birinde CPU benzeşimini manuel olarak güncellemeniz gerekir.


irqbalancezaten çalışıyor. Belki de doğru yapılandırılmamış? Bunu nasıl kontrol edebilirim?
Alexander Gladysh

Belki sadece irqbalance'ı devre dışı bırakmalı, yeniden başlatmalı, işe yarayıp yaramadığına bakmalısın. Kesmeler varsayılan olarak oldukça iyi dengelenmiştir.
chutz

Bilginize: /proc/irq/283/smp_affinitysahiptir 01şimdi onun içinde (kimse benim en iyi bildiğim için bu makinede o şeyi değiştirdi - bu sistem varsayılan olmalıdır kadar).
Alexander Gladysh

Üzgünüm, cevabımı güncelledim. irqbalance muhtemelen suçludur. Sadece ondan kurtul. Ben varsayılan ne olması gerektiğini bilmiyorum, ama deneyimden "TÜM CPU" varsayılan gördüm.
chutz

Devre dışı bırakılması irqbalance(via ENABLED=0içinde /etc/default/irqbalance) yardım etmez. Yeniden başlatıldıktan sonra irqbalanceise stop/waiting, ancak /proc/irq/283/smp_affinityhala 01.
Alexander Gladysh

2

Doğru Intel NIC modeline sahipseniz, performansı önemli ölçüde artırabilirsiniz.

İlk paragrafı alıntılamak için:

Çok çekirdekli işlemciler ve en yeni Ethernet bağdaştırıcıları (82575, 82576, 82598 ve 82599 dahil), ayrı ayrı çekirdeklere yürütme akışları atanarak TCP iletme akışlarının optimize edilmesini sağlar. Varsayılan olarak, Linux işlemci çekirdeklerine otomatik olarak kesmeler atar. Kesintileri otomatik olarak atamak için şu anda iki yöntem vardır: bir inkernel IRQ dengeleyici ve kullanıcı alanındaki IRQ denge arka plan programı. Her ikisi de CPU kullanımını düşürebilecek ancak IP yönlendirme oranlarını en üst düzeye çıkaramayan ödünleşimler sunar. Ethernet adaptörünün kuyruklarını belirli işlemci çekirdeklerine manuel olarak sabitleyerek optimum verim elde edilebilir.

IP iletme için, bir gönderme / alma kuyruk çifti aynı işlemci çekirdeğini kullanmalı ve farklı çekirdekler arasındaki önbellek senkronizasyonunu azaltmalıdır. Bu, belirli çekirdeklere gönderme ve alma kesintileri atanarak gerçekleştirilebilir. Linux çekirdeği 2.6.27 ile başlayarak, 82575, 82576, 82598 ve 82599'da birden çok kuyruk kullanılabilir. Ek olarak, Genişletilmiş İleti İşaretli Kesintilerde (MSI-X) birden çok gönderme kuyruğu etkinleştirildi. MSI-X kullanılabilen çok sayıda kesintiyi destekler, kesintilerin daha hassas kontrolüne ve kesimlerin belirli CPU'lara hedeflenmesine olanak tanır.

Bkz. Intel® 82575/82576 veya 82598/82599 Ethernet Denetleyicisi kullanarak İşlemci Çekirdeklerine Kesme Atama


2

Aslında , özellikle kısa bir süre boyunca tekrarlanan süreçlerle uğraşırken, bir cihaz kuyruğu tarafından üretilen tüm kesintilerin IRQ dengelemesi yerine aynı CPU tarafından işlenmesi ve böylece tek bir CPU eth1 kesmesini ele alırsa daha iyi performans görmeniz önerilir. *** aşağıda belirtilen istisna

Yukarıda bağlantı verilen kaynak Linux Sempozyumundadır ve SMP IRQ Affinity ile ilgili birkaç paragrafı okumanızı tavsiye ederim çünkü sizi bu yayından daha etkili bir şekilde ikna edecektir.

Neden?

Her işlemcinin ana belleğe erişmekten başka bir önbelleği olduğunu hatırlayın, bu şemaya bakın . Bir kesme tetiklendiğinde, bir CPU çekirdeğinin kesmeyi ana bellekten işlemek için talimatları alması gerekir, bu da önbellekteki talimatlardan çok daha uzun sürer. Bir işlemci bir görevi yerine getirdikten sonra önbellekte bu talimatlar olacaktır. Şimdi, aynı CPU çekirdeğinin neredeyse her zaman aynı kesmeyi işlediğini, kesme işleyici işlevinin CPU çekirdeği önbelleğinden çıkma olasılığını düşürerek çekirdek performansını artıracağını söyleyin.

Alternatif olarak, IRQ dengelendiğinde, farklı CPU tarafından sürekli olarak işlenecek kesintiyi atayabilir, o zaman yeni CPU çekirdeği muhtemelen önbellekte kesme işleyici işlevine sahip olmayacak ve uygun işleyiciyi anadan almak için uzun bir süre gerekecektir. hafıza.

İstisna : Eğer nadiren eth1 interrupt kullanıyorsanız, diğer görevleri yaparak önbelleğin üzerine yazılması için yeterli zaman geçmesi anlamına gelir, yani bu arayüz üzerinden aradaki uzun sürelerle aralıklı olarak gelen verileriniz vardır ... o zaman muhtemelen bu faydaları görmezsiniz çünkü bir işlemi yüksek frekansta kullandığınız zaman.

Sonuç

Kesmeniz çok sık gerçekleşiyorsa, yalnızca belirli bir CPU tarafından işlenecek olan kesmeyi bağlayın. Bu yapılandırma şurada yaşıyor:

 /proc/'IRQ number'/smp_affinity

veya

/proc/irq/'IRQ number'/smp_affinity

Yukarıda bağlantılı kaynaktan SMP IRQ Affinity bölümündeki son paragrafa bakın , talimatları vardır.

alternatif olarak

Şebeke izin veriyorsa MTU boyutunu (jumbo çerçeveler) artırarak kesme bayrağının yükseltilme sıklığını değiştirebilir veya her paket yerine daha fazla paket alındıktan sonra bayrağın yükseltilmesini değiştirebilirsiniz. zaman aşımına uğrarsa, belirli bir süre sonra kesmeyi yükseltin. Zaman seçeneğine dikkat edin, çünkü arabellek boyutunuz zaman dolmadan dolmuş olabilir. Bu , bağlantılı kaynakta ana hatları verilen ettool kullanılarak yapılabilir .

Bu cevap insanların okumayacağı uzunluğa yaklaşıyor, bu yüzden çok ayrıntıya girmeyeceğim, ancak durumunuza bağlı olarak birçok çözüm var ... kaynağı kontrol edin :)

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.