CPU0 bị ngập trong các ngắt eth1

Tôi đã có một máy ảo Ubuntu, chạy bên trong Xen XCP dựa trên Ubuntu. Nó lưu trữ một dịch vụ HTTP dựa trên FCGI tùy chỉnh, phía sau nginx.

Dưới tải từ ab lõi CPU đầu tiên đã bão hòa và phần còn lại được tải dưới.

Trong /proc/interruptstôi thấy rằng CPU0 phục vụ một trật tự cường độ lớn hơn bất kỳ lõi nào khác. Hầu hết trong số họ đến từ eth1.

Tôi có thể làm gì để cải thiện hiệu năng của VM này không? Có cách nào để cân bằng các ngắt đều hơn không?

Thông tin chi tiết:

$ uname -a
Linux MYHOST 2.6,38-15-ảo # 59-Ubuntu SMP Thứ Sáu 27 tháng 4 16:40:18 UTC 2012 i686 i686 i386 GNU / Linux

$ lsb_release -a
Không có mô-đun LSB có sẵn.
ID nhà phân phối: Ubuntu
Mô tả: Ubuntu 11.04
Phát hành: 11.04
Tên mã: natty

$ cat / Proc / ngắt 
           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
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 được đặt lại7
292: 0 0 0 0 0 0 0 60064 xen-percpu-ipi spinlock7
293: 0 0 0 0 0 0 0 12355510 hẹn giờ xen-percpu-virq7
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 gỡ lỗi6
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 được đặt lại6
298: 0 0 0 0 0 0 64976 0 xen-percpu-ipi spinlock6
299: 0 0 0 0 0 0 15294870 0 bộ đếm thời gian 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 được đặt lại5
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 hẹn giờ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 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 được đặt lại4
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 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 được đặt lại3
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 được đặt lại2
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 được đặt lại1
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 được đặt lại0
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 timer0
NMI: 0 0 0 0 0 0 0 0 Ngắt không thể che dấu
LỘC: 0 0 0 0 0 0 0 0 Ngắt hẹn giờ cục bộ
SPU: 0 0 0 0 0 0 0 0 Ngắt giả
PMI: 0 0 0 0 0 0 0 0 Ngắt giám sát hiệu suất
IWI: 0 0 0 0 0 0 0 0 IRQ làm việc bị gián đoạn
RES: 3607120 3551629 3422476 3802992 3482146 3468144 5374762 3236015 Ngắt lại lịch
CAL: 770084 489287 952799 544546 919884 343765 863201 373596 Ngắt cuộc gọi chức năng
TLB: 0 0 0 0 0 0 0 0 TLB bắn hạ
TRM: 0 0 0 0 0 0 0 0 Ngắt sự kiện nhiệt
THR: 0 0 0 0 0 0 0 0 Ngưỡng APIC ngắt
MCE: 0 0 0 0 0 0 0 0 Kiểm tra ngoại lệ máy
MCP: 0 0 0 0 0 0 0 0 Kiểm tra máy thăm dò ý kiến
LRI: 0
MIS: 0

Nhìn vào /proc/irq/283thư mục. Có một smp_affinity_listtập tin cho thấy CPU nào sẽ bị gián đoạn 283. Đối với bạn tệp này có thể chứa "0" (và smp_affinitycó thể chứa "1").

Bạn có thể ghi phạm vi CPU vào smp_affinity_listtệp:

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

Hoặc bạn có thể viết một bitmask, trong đó mỗi bit tương ứng với CPU, để smp_affinity:

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

Tuy nhiên, irqbalance được biết là có ý tưởng riêng của mình về những gì mối quan hệ từng ngắt cần phải có, và nó có thể trở lại cập nhật của bạn. Vì vậy, tốt nhất là nếu bạn chỉ gỡ bỏ hoàn toàn mất cân bằng. Hoặc ít nhất là ngăn chặn nó và vô hiệu hóa nó khi khởi động lại.

Nếu ngay cả khi không có sự mất cân bằng, bạn sẽ bị lẻ smp_affinitykhi bị gián đoạn 283 sau khi khởi động lại, bạn sẽ phải cập nhật thủ công mối quan hệ CPU trong một trong các tập lệnh khởi động của bạn.

Nếu bạn có mô hình Intel NIC phù hợp, bạn có thể cải thiện hiệu suất đáng kể.

Để trích dẫn đoạn đầu tiên:

Bộ xử lý đa lõi và bộ điều hợp Ethernet mới nhất (bao gồm 82575, 82576, 82598 và 82599) cho phép các luồng chuyển tiếp TCP được tối ưu hóa bằng cách gán các luồng thực thi cho các lõi riêng lẻ. Theo mặc định, Linux tự động gán các ngắt cho các lõi xử lý. Hai phương thức hiện đang tồn tại để tự động gán các ngắt, bộ cân bằng IRQ dạng hạt và trình nền cân bằng IRQ trong không gian người dùng. Cả hai đều cung cấp sự đánh đổi có thể làm giảm mức sử dụng CPU nhưng không tối đa hóa tốc độ chuyển tiếp IP. Thông lượng tối ưu có thể thu được bằng cách ghim thủ công các hàng đợi của bộ điều hợp Ethernet vào các lõi của bộ xử lý cụ thể.

Để chuyển tiếp IP, một cặp hàng đợi truyền / nhận nên sử dụng cùng một lõi bộ xử lý và giảm bất kỳ đồng bộ hóa bộ đệm giữa các lõi khác nhau. Điều này có thể được thực hiện bằng cách gán các ngắt truyền và nhận cho các lõi cụ thể. Bắt đầu với nhân Linux 2.6.27, nhiều hàng đợi có thể được sử dụng trên 82575, 82576, 82598 và 82599. Ngoài ra, nhiều hàng đợi truyền được bật trong Ngắt tín hiệu nhắn tin mở rộng (MSI-X). MSI-X hỗ trợ số lượng lớn hơn các ngắt có thể được sử dụng, cho phép kiểm soát chi tiết hơn và nhắm mục tiêu các ngắt đến các CPU cụ thể.

Xem: Gán các ngắt cho Lõi bộ xử lý bằng Bộ điều khiển Ethernet Intel® 82575/82576 hoặc 82598/82599

Trên thực tế , đặc biệt là khi xử lý các quá trình lặp đi lặp lại trong một khoảng thời gian ngắn, tất cả các gián đoạn được tạo bởi hàng đợi thiết bị được xử lý bởi cùng một CPU, thay vì cân bằng IRQ và do đó bạn sẽ thấy hiệu suất tốt hơn nếu một CPU xử lý ngắt eth1 *** ngoại lệ được cung cấp dưới đây

Nguồn, được liên kết ở trên, là từ Hội nghị chuyên đề về Linux và tôi khuyên bạn nên đọc qua một vài đoạn trên SMP IRQ Affinity vì nó sẽ thuyết phục bạn hiệu quả hơn bài đăng này.

Tại sao?

Nhớ lại mỗi bộ xử lý có bộ đệm riêng ngoài khả năng truy cập bộ nhớ chính, hãy xem sơ đồ này . Khi ngắt được kích hoạt, lõi CPU sẽ phải tìm nạp các hướng dẫn để xử lý ngắt từ bộ nhớ chính, mất nhiều thời gian hơn so với các hướng dẫn trong bộ đệm. Khi một bộ xử lý thực thi một tác vụ, nó sẽ có các hướng dẫn đó trong bộ đệm. Bây giờ nói rằng cùng một lõi CPU xử lý cùng một ngắt gần như mọi lúc, chức năng xử lý ngắt sẽ không thể rời khỏi bộ đệm lõi CPU, tăng hiệu năng của nhân.

Ngoài ra, khi IRQ được cân bằng, nó có thể chỉ định gián đoạn được xử lý liên tục bởi các CPU khác nhau, thì lõi CPU mới có thể sẽ không có chức năng xử lý ngắt trong bộ đệm, và sẽ cần một thời gian dài để có được trình xử lý thích hợp từ chính ký ức.

Ngoại lệ : nếu bạn đang sử dụng hiếm khi eth1 ngắt, có nghĩa là đủ thời gian trôi qua mà bộ nhớ cache được ghi đè bằng cách thực hiện các nhiệm vụ khác, có nghĩa là bạn có dữ liệu đến trên giao diện mà không liên tục với thời gian dài ở giữa ... sau đó nhiều khả năng bạn sẽ không nhìn thấy những lợi ích này vì chúng là khi bạn sử dụng một quá trình với tần suất cao.

Phần kết luận

Nếu ngắt của bạn xảy ra rất thường xuyên thì chỉ cần liên kết ngắt đó để được xử lý bởi một CPU cụ thể. Cấu hình này sống ở

 /proc/'IRQ number'/smp_affinity

hoặc là

/proc/irq/'IRQ number'/smp_affinity

Xem đoạn cuối trong phần ái lực SMP IRQ từ nguồn được liên kết ở trên, nó có hướng dẫn.

Hoặc

Bạn có thể thay đổi tần số mà cờ ngắt được tăng lên bằng cách tăng kích thước MTU (khung jumbo) nếu mạng cho phép hoặc thay đổi để tăng cờ sau khi nhận được số lượng gói lớn hơn thay vì tại mỗi gói HOẶC thay đổi hết thời gian, vì vậy tăng gián đoạn sau một khoảng thời gian nhất định. Thận trọng với tùy chọn thời gian vì kích thước bộ đệm của bạn có thể đầy trước khi hết thời gian. Điều này có thể được thực hiện bằng cách sử dụng ethtool được nêu trong nguồn được liên kết.

Câu trả lời này đang tiến gần đến độ dài mà mọi người sẽ không đọc nó vì vậy tôi sẽ không đi sâu vào chi tiết, nhưng tùy thuộc vào tình huống của bạn, có nhiều giải pháp ... kiểm tra nguồn :)