ESX 因 IRQ 共享而出现性能问题
search cancel

ESX 因 IRQ 共享而出现性能问题

book

Article ID: 304750

calendar_today

Updated On:

Products

VMware vSphere ESXi

Issue/Introduction

Symptoms:
免责声明：本文为 ESX has performance issues due to IRQ sharing (1003710) 的翻译版本。尽管我们会不断努力为本文提供最佳翻译版本，但本地化的内容可能会过时。有关最新内容，请参见英文版本。

VMkernel 在系统初始化时为所有 PCI 设备分配中断请求 (IRQ) 编号。IRQ 分配取决于系统的硬件拓扑和可用 IRQ 的数量。如果由于硬件约束而限制了可用 IRQ 的数量，则可以为两个或多个 PCI 设备分配相同的 IRQ 编号。在大多数情况下，这一中断共享现象在 ESX Server 系统上的影响微乎其微。但在有些情况下，可能对 ESX Server 性能有严重影响。
注意：
  • 由于出现 IRQ 共享问题的必要条件之一是设备由服务控制台所拥有，ESXi 不会遇到该问题，因为它没有服务控制台。
  • 这不是 ESX 4.0 中的问题，因为 IRQ 直接加载到 VMkernel 中（因此服务控制台中不会出现冲突）。


Environment

VMware ESX Server 3.5.x

Resolution

了解 ESX Server 中的 IRQ 共享

注意：本文旨在帮助您识别可能的 IRQ 共享问题并确定潜在解决方案。有关 IRQ 和 IRQ 规范的详细信息，请联系系统供应商。

要使 PCI 设备能够中断 CPU，PCI 总线上的所有 PCI 设备都分配有一个 IRQ 编号。VMkernel 使用 BIOS 提供的发现和中断重新路由机制分配这些 IRQ 编号。但是，在某些情况下，由于硬件设计的原因，两个或多个设备可能连接到同一个中断控制器 PIN。因此，两个或多个设备最终共享同一个 IRQ。在正常环境中没有性能影响，也察觉不到 IRQ 共享。

在 ESX Server 3.5 中，设备可由服务控制台或 VMkernel 所拥有。由于中断处理需要额外的上下文切换，因此服务控制台所拥有的设备的中断处理开销比 VMkernel 所拥有的设备高很多。因此，中断率高的设备不应分配给服务控制台。

当两个低中断率设备之间出现 IRQ 共享并且这两个设备均为服务控制台所拥有，或者均由 VMkernel 所拥有时，对性能的影响微乎其微。但是当一个 IRQ 共享设备由服务控制台所拥有，而另一个由 VMkernel 所拥有时，可能有明显的性能影响。而当两个设备均为高中断率时，影响更严重（并且容易观察到）。

性能影响有两个原因：

  • 服务台与 VMkernel 之间共享的中断线由于额外的上下文切换而导致开销增高。发出共享中断后，VMkernel 不能直接确定是哪个设备导致的中断。CPU 于是按顺序为使用该中断的所有设备运行所有中断服务例行程序，直至找到导致中断的设备。如果共享设备由 VMkernel 所拥有，则运行此中断例行程序链不会花费很多时间。但是，当 VMkernel 与服务控制台共享 IRQ 时，执行中断例行程序序列会导致每次中断都切换上下文。这对性能有明显影响。
  • IRQ 共享将中断处理限制为一个单独的 CPU。ESX Server 设计为充分利用可用的硬件资源以达到最佳性能。在正常情况下，中断处理分布于系统中不同的内核，选择使用率最低的内核。但是，当 VMkernel 中设备的 IRQ 由属于服务控制台的设备共享时，该中断处理限制到 CPU #0。在中断率高的设备中，CPU #0 成为处理瓶颈。如果服务控制台也在 CPU #0 上运行，即使其资源消耗很小，也会进一步加重瓶颈问题。

确定 IRQ 共享问题是否影响系统性能

VMkernel 与服务控制台之间的 IRQ 共享的显示迹象是由 PCPU0（物理主机上的 CPU #0）提供的中断的数量高，而其他 CPU 负载相对低。高中断率有时可能表现为服务控制台不可用，并导致 ESX Server 性能变化明显。

导致 IRQ 共享的最常见的服务控制台设备是 USB 控制器。在 VMkernel 一端，网络和存储控制器容易出现 IRQ 共享。IRQ 共享在双端口和四端口网卡和存储 HBA 中比在单端口控制器中更常见。但是，IRQ 共享并不仅限于这些设备。在 I/O 密集型负载（高中断率）条件下影响更明显。问题可能表现为性能有变化或者 ESX Server 性能明显下降。

要确定安装是否遇到 IRQ 共享，在服务控制台的命令行键入以下内容列出 VMkernel 中的 IRQ 分配：

> cat /proc/vmware/interrupts

这将列出中断使用情况。输出类似于以下示例：

Vector PCPU 0 PCPU 1 PCPU 2 PCPU 3
        0x21: 0 0 0 0 VMK ACPI Interrupt
        0x29: 1 0 0 0 <COS irq 1 (ISA edge)>, VMK keyboard
        0x31: 4 0 0 0 <COS irq 3 (ISA edge)>
        0x39: 4 0 0 0 <COS irq 4 (ISA edge)>
        0x41: 0 0 0 0 <COS irq 6 (ISA edge)>
        0x49: 0 0 0 0 <COS irq 7 (ISA edge)>
        0x51: 0 0 0 0 <COS irq 8 (ISA edge)>
        0x59: 0 0 0 0 <COS irq 12 (ISA edge)>
        0x61: 0 0 0 0 <COS irq 13 (ISA edge)>
        0x69: 43762 0 0 0 COS irq 14 (ISA edge)
        0x71: 0 0 0 0 <COS irq 15 (ISA edge)>
        0x79: 7917 542 3583 8292 <COS irq 16 (PCI level)>, VMK aic79xx
        0x81: 1544 0 0 0 COS irq 17 (PCI level), VMK aic79xx
        0x89: 1212177 0 0 0 COS irq 19 (PCI level), VMK vmnic1
        0x91: 90997 0 0 0 COS irq 18 (PCI level), VMK vmnic0
        0x99: 152 0 0 0 <COS irq 20 (PCI level)>, VMK qla2300
               0xdf: 8904447 10869326 11006262 10844861 VMK timer
          0xe1: 74 5582 12007 16005 VMK monitor
          0xe9: 60854 443843 477389 509724 VMK resched
          0xec: 0 0 0 0 VMK ucodeUpdate
          0xf1: 3 40 68 100 VMK tlb
          0xf9: 243265 0 0 0 VMK noop
          0xfc: 0 0 0 0 VMK thermal
        0xfd: 0 0 0 0 VMK lint1
        0xfe: 0 0 0 0 VMK error
        0xff: 0 0 0 0 VMK spurious 

   
该输出列出了中断向量数以及每个物理 CPU (PCPU) 产生的中断数。最后一列列出与特殊 IRQ 相关联的一个或多个设备。设备所有者随着设备名一起列出。COS 指服务控制台所有权，VMK 指 VMkernel 所有权。（在旧版 ESX Server 中，服务控制台称为控制台操作系统或 COS。）
 
 
 
如果是以分析为目的，可以忽略尖括号 (<>) 内的服务控制台所拥有的设备，因为服务控制台不为这些设备加载驱动程序。拥有一个设备，并且旁边显示 COS 和 VMK 的所有其他中断向量表示该设备共享 IRQ。此外，可以忽略低中断率设备（例如 0x81 和 0x99），因为这些设备对性能的影响极小。
 
 
 
在上例中，IRQ 0x81、0x89、0x91 和 0x99 在服务控制台与 VMK 设备之间共享。无需分析 0x81 和 0x99 的中断计数，因为计数值相当低。还要注意，这四个 IRQ 的所有中断均为 PCPU 0 所产生，而所有其他 PCPU 显示零中断计数。相反，中断向量 0x89 和 0x91（用于 vmnic1 和 vmnic0）显示高中断计数。服务控制台中 vmnic1 和 vmnic0 的共享 IRQ 分别为 IRQ 19 和 IRQ 18。
 
 
 
在本例中，需要从服务控制台移除与 vmnic0 和 vmnic1 冲突的设备。要在服务控制台中找到引发问题的设备，列出中断向量：
 
> cat /proc/interrupts
 
这将列出分配给服务控制台中的设备的 IRQ 线。
CPU0
          0: 1744046 vmnix-edge timer
          1: 3 vmnix-edge keyboard
          2: 163071 vmnix-edge VMnix interrupt
          14: 44022 vmnix-edge ide0
          17: 1499 vmnix-level usb-uhci, ehci-hcd
          18: 91236 vmnix-level usb-uhci
          19: 1303228 vmnix-level usb-uhci
          NMI: 0
          LOC: 0
          ERR: 0
          MIS: 0    
 
您可以看到 IRQ 18 和 IRQ 19 正由 USB 通用主机控制器设备 usb-uhci 使用。
 
解决 IRQ 共享问题 
 
要解决 IRQ 共享冲突，请执行以下操作：
 
  • 禁用有问题的设备（如果未使用）。  
  • 将该设备移至其他 PCI 插槽。  
  • 合并处理服务控制台设备中断（仅在 ESX 3.5 Update 5 中） 
 
注意：在禁用 USB 设备之前，请与硬件供应商核实该设备是否由任何远程访问卡使用。 
 
禁用设备 
 
如果服务控制台中冲突的设备（此处为 USB 控制器）未使用，则禁用该设备。使用以下命令移除 usb-uhci 模块：
 
 
 
> rmmod usb-uhci
 
 
 
对于自己的系统，将 usb-uhci 替换为通过特定输出确定的相应设备。
 
 
 
其他替代措施包括：
 
  • 阻止服务控制台为设备加载驱动程序也涉及中断共享。为阻止服务控制台加载设备的驱动程序，从文件 /etc/modules.conf 中移除对驱动程序的引用。  
  • 从 BIOS 本身禁用 USB 设备（对于特定系统）。在 BIOS 中禁用 USB 控制器还可以防止在后续重新引导周期加载 USB 驱动程序。  
  • 在已知有中断共享问题的硬件上，安装 ESXi Server 代替 ESX Server 可以避免出现中断问题。
 
备注：
 
 
 
 
  • 如果通过 BIOS 操作（例如禁用 USB 或可以降级至 V1.1）可以避免冲突，则首选该方法，因为该修复在以后升级时也将持久保留。  
  • 如果运行 rmmod 或修改 modules.conf，则必须在升级后重复该过程。 
 

现在，/proc/interrupts 的输出为：
 
 CPU0  
        0: 8690704 vmnix-edge timer
          1: 3 vmnix-edge keyboard
          2: 2238513 vmnix-edge VMnix interrupt
          14: 212504 vmnix-edge ide0
          17: 1715 vmnix-level ehci-hcd
          NMI: 0
          LOC: 0
          ERR: 0
          MIS: 0  
 
 
 
注意，COS IRQ 18 和 IRQ 19 不再使用。在 vmnic0 和 vmnic1 上运行网络工作负载，并检查 proc/vmware/interrupts。输出内容类似于： 
Vector PCPU 0 PCPU 1 PCPU 2 PCPU 3
          ...
          0x71: 0 0 0 0 <COS irq 15 (ISA edge)>
          0x79: 32895 36823 68596 74985 <COS irq 16 (PCI level)>,VMK aic79xx
          0x81: 1760 0 0 0 COS irq 17 (PCI level), VMK aic79xx
          0x89: 1596687 26796 534484 289717 <COS irq 19 (PCI level)>, VMK vmnic1
          0x91: 344252 1035 1951 768 <COS irq 18 (PCI level)>, VMK vmnic0
          0x99: 616 0 0 0 <COS irq 20 (PCI level)>,VMK qla2300
             0xdf: 45701368 115529363 127721751 128342600 VMK timer
               ...  
   
注意，中断现在分布于所有可用的 CPU。现在，COS irq18 和 COS irq19 在尖括号中，这表示服务控制台中未载入模块，没有中断共享。
 
移动设备
 
在某些情况下，无法禁用特殊服务控制台设备，因为服务控制台正确运行需要这些设备（例如，某些以太网控制器）。在这种情况下，尝试将卡移至其他 PCI 插槽。由于分配给设备的中断线由设备在计算机中的物理位置所决定，因此更改插卡位置会导致重新分配 IRQ 编号。务必要在更改插卡位置后重新检查所有控制器是否有中断共享。
 
 
 
合并处理服务控制台设备中断（仅在 ESX 3.5 Update 5 中）
 
 
 
如上文所述，由于 IRQ 共享所造成的性能影响可能有两个原因，即，服务控制台上下文切换开销和 CPU #0 处理瓶颈。无论哪个原因都会导致与服务控制台共享 IRQ 的 VMkernel 设备的吞吐量下降。此外，CPU #0 上的处理瓶颈也会影响服务控制台性能。对于影响很大程度是由于上下文切换开销所造成的情况，ESX 3.5 Update 5 加入了一个方法，这种方法将与 VMkernel 设备共享 IRQ 的服务控制台设备中断的处理合并，以提高性能。 
 
 
 
默认情况下禁用该方法。启用后，仅在超过可配置的阈值后才对中断进行合并和处理。当中断是由共享 IRQ 的 VMkernel 设备生成时，这种方法可以减少服务控制台所处理的伪中断的数量。因此，由于上下文切换减少，可以提高性能。但是，这种方法不利于处理来自服务控制台的真正的中断，因为在超出合并阈值之前，会重新传送未确认的中断。考虑到在典型方案中，低中断率服务控制台设备与高中断率 VMkernel 设备共享 IRQ，因此这种取舍值得尝试，应能使整体性能获益。
 
 
 
合并阈值的有效值为 0 到 10。默认设置为 0，表示禁用合并。设置一个非零的值将指定在服务控制台为任何共享 IRQ 处理一个中断之前已合并的中断数。我们建议设置最低值，在该值能够观察到可接受的性能提高。合并阈值只能在 ESX 3.5 Update 5 中按如下所述从 VMware Infrastructure Client 查询和设置：
 
  1.  
    单击配置选项卡。
     
  2.  
    单击高级设置。
     
  3.  
    查看或设置 Irq.IRQNumHostPend。
 
或者，从服务控制台运行以下命令： 
 
     
    • esxcfg-advcfg --get /Irq/IRQNumHostPend 
    • esxcfg-advcfg --set <value> /Irq/IRQNumHostPend


    
                            
    
                        
    
                    

                    
                        
    
                            
    
                                
    Additional Information
    
                            
    
                            
    
                                ESX has performance issues due to IRQ sharing

    
                            
    
                        
    
                    
                    
                    

                    

                
    
                
    
                    Powered by
                      
                Wolken Software