CPU0 ล้นมือด้วยการขัดจังหวะ eth1

ฉันมี Ubuntu VM ซึ่งทำงานใน Xen XCP ที่ทำงานบน Ubuntu มันเป็นเจ้าภาพจัดบริการ HTTP ที่กำหนดเอง FCGI nginxตามหลัง

ภายใต้การโหลดจากab ซีพียูคอร์แรกนั้นอิ่มตัวและส่วนที่เหลืออยู่ภายใต้การโหลด

ใน/proc/interruptsฉันเห็นว่าCPU0 ทำหน้าที่ลำดับความสำคัญมากกว่าการขัดจังหวะแกนกลางอื่น ๆ eth1ส่วนใหญ่ของพวกเขามาจาก

มีอะไรที่ฉันสามารถทำได้เพื่อปรับปรุงประสิทธิภาพของ VM นี้หรือไม่? มีวิธีการสมดุลการขัดจังหวะอย่างเท่าเทียมกันมากขึ้นหรือไม่?

รายละเอียดเลือด:

$ uname -a
Linux MYHOST 2.6.38-15-virtual # 59-Ubuntu SMP ศุกร์ 27 เม.ย. 16:40:18 UTC 2012 i686 i686 i386 GNU / Linux

$ lsb_release -a
ไม่มีโมดูล LSB
ID ผู้จัดจำหน่าย: Ubuntu
คำอธิบาย: Ubuntu 11.04
เผยแพร่: 11.04
สมญานาม: natty

$ cat / proc / ขัดจังหวะ 
           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 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 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 xen-percpu-virq timer6
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 xen-percpu-virq timer5
306: 0 0 0 0 844591 0 0 0 xen-percpu-ipi callfuncsingle4
307: 0 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 xen-percpu-virq timer4
312: 0 0 0 449141 0 0 0 0 xen-percpu-ipi callfuncsingle3
313: 0 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 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 timer2
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 xen-percpu-virq timer1
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 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 0 xen-percpu-ipi spinlock0
335: 89912004 0 0 0 0 0 0 0 xen-percpu-virq timer0
NMI: 0 0 0 0 0 0 0 0 อินเตอร์รัปต์ที่ไม่สามารถพรางได้
LOC: 0 0 0 0 0 0 0 0 Local timer อินเตอร์รัปต์
SPU: 0 0 0 0 0 0 0 0 การขัดจังหวะปลอม
PMI: 0 0 0 0 0 0 0 0 การขัดจังหวะการตรวจสอบประสิทธิภาพ
IWI: 0 0 0 0 0 0 0 0 IRQ งานขัดจังหวะ
RES: 3607120 3551629 3422476 3802992 3482146 3468144 5374762 3236015 การจัดกำหนดการอินเตอร์รัปต์ใหม่
CAL: 770084 489287 952799 544546 919884 343765 863201 373596 การขัดจังหวะการเรียกใช้ฟังก์ชัน
TLB: 0 0 0 0 0 0 0 0 TLB shootdowns
TRM: 0 0 0 0 0 0 0 0 เหตุการณ์ความร้อนขัดจังหวะ
THR: 0 0 0 0 0 0 0 0 เกณฑ์ขัดจังหวะ APIC
MCE: 0 0 0 0 0 0 0 0 การตรวจสอบเครื่องยกเว้น
MCP: 0 0 0 0 0 0 0 0 โพลตรวจสอบเครื่องจักร
ข้อผิดพลาด: 0
MIS: 0

ดูใน/proc/irq/283ไดเรกทอรี มีsmp_affinity_listไฟล์ซึ่งแสดงให้เห็นว่าซีพียูใดจะได้รับการขัดจังหวะ 283 สำหรับคุณไฟล์นี้อาจมี "0" (และsmp_affinityอาจมี "1")

คุณสามารถเขียนช่วง CPU ไปยังsmp_affinity_listไฟล์:

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

หรือคุณสามารถเขียน bitmask โดยที่แต่ละบิตสอดคล้องกับ CPU ไปที่smp_affinity:

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

อย่างไรก็ตามirqbalanceนั้นเป็นที่ทราบกันดีว่ามีความคิดเกี่ยวกับความสัมพันธ์ที่ขัดจังหวะในแต่ละครั้ง ดังนั้นจะเป็นการดีที่สุดถ้าคุณถอนการติดตั้ง irqbalance อย่างสมบูรณ์ หรืออย่างน้อยก็หยุดมันและปิดการใช้งานจากการเริ่มต้นใหม่

ถ้าแม้ไม่มี irqbalance คุณกำลังแปลกsmp_affinityสำหรับขัดจังหวะ 283 หลังจากรีบูตคุณจะต้องปรับปรุงความสัมพันธ์ CPU ด้วยตนเองในสคริปต์เริ่มต้นของคุณอย่างใดอย่างหนึ่ง

หากคุณมีรุ่นที่เหมาะสมของ Intel NIC คุณสามารถปรับปรุงประสิทธิภาพได้อย่างมาก

หากต้องการอ้างอิงย่อหน้าแรก:

โปรเซสเซอร์แบบมัลติคอร์และอะแดปเตอร์อีเทอร์เน็ตรุ่นใหม่ล่าสุด (รวมถึง 82575, 82576, 82598 และ 82599) อนุญาตให้กระแสการส่งต่อ TCP ได้รับการปรับให้เหมาะสมโดยกำหนดกระแสการประมวลผลให้กับแต่ละคอร์ ตามค่าเริ่มต้น Linux จะกำหนดการขัดจังหวะให้กับแกนประมวลผลโดยอัตโนมัติ ปัจจุบันมีสองวิธีในการกำหนดอินเทอร์รัปต์โดยอัตโนมัตินั่นคือ IRQ balancer และ IRQ balance daemon ในพื้นที่ผู้ใช้ ทั้งสองข้อเสนอแลกเปลี่ยนที่อาจลดการใช้ CPU แต่ไม่เพิ่มอัตราการส่งต่อ IP สูงสุด สามารถรับปริมาณงานได้สูงสุดโดยการตรึงคิวของอะแดปเตอร์อีเทอร์เน็ตด้วยตนเองไปที่แกนประมวลผลเฉพาะ

สำหรับการส่งต่อ IP คู่ของคิวการส่ง / รับควรใช้ตัวประมวลผลหลักเดียวกันและลดการซิงโครไนซ์แคชระหว่างคอร์ที่ต่างกัน สิ่งนี้สามารถทำได้โดยการกำหนดการส่งและรับการขัดจังหวะไปยังแกนที่เฉพาะเจาะจง เริ่มต้นด้วยเคอร์เนล 2.6.27 หลายคิวสามารถใช้กับ 82575, 82576, 82598 และ 82599 นอกจากนี้คิวการส่งสัญญาณหลายตัวยังเปิดใช้งานใน Extended Messaging Signaled Interrupts (MSI-X) MSI-X รองรับการขัดจังหวะจำนวนมากที่สามารถใช้งานได้ช่วยให้สามารถควบคุมและกำหนดเป้าหมายของการขัดจังหวะการทำงานของซีพียูที่เฉพาะเจาะจงยิ่งขึ้น

ดู: การกำหนดอินเตอร์รัปต์ให้กับคอร์โปรเซสเซอร์โดยใช้Intel® 82575/82576 หรือ 82598/82599 Ethernet Controller

อันที่จริงก็จะแนะนำโดยเฉพาะอย่างยิ่งเมื่อต้องรับมือกับกระบวนการซ้ำในช่วงระยะเวลาสั้น ๆ ที่หยุดชะงักทั้งหมดที่สร้างโดยคิวอุปกรณ์จะถูกจัดการโดย CPU เดียวกันแทนที่จะ IRQ สมดุลและทำให้คุณจะเห็นประสิทธิภาพที่ดีขึ้นถ้า CPU เดียวจัดการขัดจังหวะ eth1 *** มีข้อยกเว้นด้านล่าง

แหล่งที่มาเชื่อมโยงข้างต้นมาจาก Linux Symposium และฉันขอแนะนำให้คุณอ่านสองย่อหน้าในSMP IRQ Affinityเพราะจะทำให้คุณมีประสิทธิภาพมากกว่าโพสต์นี้

ทำไม?

จำโปรเซสเซอร์แต่ละตัวมีแคชของตัวเองนอกเหนือจากความสามารถในการเข้าถึงหน่วยความจำหลักลองดูที่แผนภาพนี้ เมื่อเกิดการขัดจังหวะ CPU core จะต้องดึงคำแนะนำเพื่อจัดการการขัดจังหวะจากหน่วยความจำหลักซึ่งใช้เวลานานกว่าคำสั่งที่อยู่ในแคช เมื่อตัวประมวลผลดำเนินการงานมันจะมีคำแนะนำเหล่านั้นในแคช ตอนนี้บอกว่าซีพียูแกนเดียวกันจัดการการขัดจังหวะเดียวกันเกือบตลอดเวลาฟังก์ชั่นการจัดการขัดจังหวะจะไม่น่าจะออกจากแคชคอร์แกน CPU เพิ่มประสิทธิภาพเคอร์เนล

อีกทางเลือกหนึ่งเมื่อ IRQ มีความสมดุลสามารถกำหนดให้การขัดจังหวะได้รับการจัดการอย่างต่อเนื่องโดยซีพียูที่แตกต่างกันจากนั้นซีพียูแกนใหม่อาจจะไม่มีฟังก์ชั่นการจัดการขัดจังหวะในแคชและจะต้องใช้เวลานาน หน่วยความจำ

ข้อยกเว้น : หากคุณไม่ค่อยใช้การขัดจังหวะ eth1 หมายความว่ามีเวลามากพอที่แคชจะถูกเขียนทับโดยการทำงานอื่น ๆ ซึ่งหมายความว่าคุณมีข้อมูลที่ผ่านอินเตอร์เฟซนั้นเป็นระยะ ๆ ด้วยระยะเวลานาน ... คุณอาจไม่เห็นประโยชน์เหล่านี้ สำหรับพวกเขาเมื่อคุณใช้กระบวนการที่ความถี่สูง

ข้อสรุป

หากการขัดจังหวะของคุณเกิดขึ้นบ่อยมากให้ผูกการขัดจังหวะนั้นไว้เพื่อจัดการโดย CPU เฉพาะเท่านั้น การกำหนดค่านี้อยู่ที่

 /proc/'IRQ number'/smp_affinity

หรือ

/proc/irq/'IRQ number'/smp_affinity

ดูย่อหน้าสุดท้ายในส่วนความสัมพันธ์ SMP IRQจากแหล่งข้อมูลที่เชื่อมโยงด้านบนมีคำแนะนำ

อีกทางเลือกหนึ่ง

คุณสามารถเปลี่ยนความถี่ที่มีการเพิ่มค่าสถานะอินเตอร์รัปต์โดยเพิ่มขนาด MTU (เฟรมจัมโบ้) หากเครือข่ายอนุญาตหรือเปลี่ยนแปลงเพื่อให้ค่าสถานะเพิ่มขึ้นหลังจากได้รับแพ็กเก็ตจำนวนมากแทนทุกแพ็กเก็ตหรือเปลี่ยน หมดเวลาดังนั้นเพิ่มการขัดจังหวะหลังจากระยะเวลาหนึ่ง ระมัดระวังด้วยตัวเลือกเวลาเนื่องจากขนาดบัฟเฟอร์ของคุณอาจเต็มก่อนหมดเวลา สิ่งนี้สามารถทำได้โดยใช้ethtoolที่ระบุไว้ในแหล่งที่เชื่อมโยง

คำตอบนี้ใกล้ถึงระยะเวลาที่ผู้คนจะไม่อ่านดังนั้นฉันจะไม่ลงรายละเอียดมากนัก แต่ขึ้นอยู่กับสถานการณ์ของคุณมีวิธีแก้ปัญหามากมาย ... ตรวจสอบแหล่งที่มา :)