¿Qué cargas de red requieren sondeo NIC vs interrupciones?

¿Alguien tiene algunos datos o cálculos básicos que puedan responder cuando se requiere la fusión de cuadros (NAPI) y cuando una sola interrupción por cuadro es suficiente?

Mi hardware: IBM BladeServer HS22, hardware Broadcom 5709 Gigabit NIC (MSI-X), con procesadores duales Xeon E5530 de cuatro núcleos. El propósito principal es el servidor proxy Squid. Switch es una buena serie Cisco 6500.

Nuestro problema básico es que durante las horas pico (tráfico de 100 Mbps, solo 10,000 pps) aumenta la latencia y la pérdida de paquetes. He realizado muchos ajustes y actualizaciones del kernel a 2.6.38 y ha mejorado la pérdida de paquetes, pero la latencia sigue siendo pobre. Los pings son esporádicos; saltando incluso a 200 ms en LAN local de Gbps. La respuesta promedio de calamar salta de 30ms a 500 + ms aunque la carga de CPU / memoria está bien

Las interrupciones suben a aproximadamente 15,000 / segundo durante el pico. Ksoftirqd no usa mucha CPU; He instalado irqbalance para equilibrar los IRQ (8 cada uno para eth0 y eth1) en todos los núcleos, pero eso no ha ayudado mucho.

Las NIC de Intel parecen nunca tener este tipo de problemas, pero debido al hecho de que el sistema de blades y el hardware de configuración fija, estamos atascados con los Broadcom.

Todo apunta a la NIC como el principal culpable. La mejor idea que tengo ahora es intentar disminuir las interrupciones mientras se mantiene baja la latencia y el rendimiento alto.

Lamentablemente, el bnx2 no admite adaptativo-rx o tx.

La respuesta de subproceso NAPI frente a interrupciones adaptativas proporciona una excelente visión general de la moderación de interrupciones, pero no proporciona información concreta sobre cómo calcular la configuración óptima de fusión de herramientas de ettool para una solución alternativa dada. ¿Existe un mejor enfoque que solo prueba y error?

¿La carga de trabajo y la configuración de hardware mencionadas anteriormente incluso necesitan NAPI? ¿O debería poder vivir con una sola interrupción por paquete?

Gran pregunta que me hizo leer un poco para tratar de resolverlo. Ojalá pudiera decir que tengo una respuesta ... pero tal vez algunas pistas.

Al menos puedo responder a su pregunta, "¿debería ser capaz de vivir con una sola interrupción por paquete". Creo que la respuesta es sí, basada en un firewall muy ocupado al que tengo acceso:

Salida Sar:

03:04:53 PM     IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s   txcmp/s  rxmcst/s
03:04:54 PM        lo     93.00     93.00      6.12      6.12      0.00      0.00      0.00
03:04:54 PM      eth0 115263.00 134750.00  13280.63  41633.46      0.00      0.00      5.00
03:04:54 PM      eth8  70329.00  55480.00  20132.62   6314.51      0.00      0.00      0.00
03:04:54 PM      eth9  53907.00  66669.00   5820.42  21123.55      0.00      0.00      0.00
03:04:54 PM     eth10      0.00      0.00      0.00      0.00      0.00      0.00      0.00
03:04:54 PM     eth11      0.00      0.00      0.00      0.00      0.00      0.00      0.00
03:04:54 PM      eth1      0.00      0.00      0.00      0.00      0.00      0.00      0.00
03:04:54 PM      eth2 146520.00 111904.00  45228.32  12251.48      0.00      0.00     10.00
03:04:54 PM      eth3    252.00  23446.00     21.34   4667.20      0.00      0.00      0.00
03:04:54 PM      eth4      8.00     10.00      0.68      0.76      0.00      0.00      0.00
03:04:54 PM      eth5      0.00      0.00      0.00      0.00      0.00      0.00      0.00
03:04:54 PM      eth6   3929.00   2088.00   1368.01    183.79      0.00      0.00      1.00
03:04:54 PM      eth7     13.00     17.00      1.42      1.19      0.00      0.00      0.00
03:04:54 PM     bond0 169170.00 201419.00  19101.04  62757.00      0.00      0.00      5.00
03:04:54 PM     bond1 216849.00 167384.00  65360.94  18565.99      0.00      0.00     10.00

Como puede ver, algunos paquetes muy altos por segundo cuentan, y no se realizaron ajustes especiales de ethtool en esta máquina. Oh ... chipset Intel, sin embargo. : \

Lo único que se hizo fue un equilibrio manual de irq con / proc / irq / XXX / smp_affinity, por interfaz. No estoy seguro de por qué decidieron seguir ese camino en lugar de ir con el equilibrio, pero parece funcionar.

También pensé en las matemáticas necesarias para responder a tu pregunta, pero creo que hay demasiadas variables. Entonces ... para resumir, en mi opinión, la respuesta es no, no creo que pueda predecir los resultados aquí, pero con suficiente captura de datos debería ser capaz de ajustarlo a un mejor nivel.

Habiendo dicho todo eso, mi intuición es que de alguna manera estás vinculado al hardware ... como en un firmware o error de interoperabilidad de algún tipo.

Ciertamente, dadas las capacidades de CPU, chipset y bus en comparación con la cantidad tan baja de tráfico que tiene, no hay ninguna razón para que NECESITA ninguna forma de gestión de interrupciones. Tenemos varias máquinas RHEL 5.3 de 64 bits con NIC de 10 Gbps y sus interrupciones no son tan malas, esto es 100 veces menos.

Obviamente tiene una configuración fija (uso blades de HP que son bastante similares), por lo que cambiar las NIC por Intels ahora es una opción fácil, pero lo que diría es que estoy empezando a detectar una serie de problemas similares en este foro y en otros lugares con esa NIC de Broadcom en particular. Alguna vez los propios sitios de SE tuvieron algunos problemas con este tipo de inconsistencia y el intercambio a NIC de Intel fue de gran ayuda.

Lo que recomendaría es elegir una sola cuchilla y agregar un adaptador basado en Intel a esa máquina, obviamente tendrá que agregar una interconexión o lo que sea que IBM les llame para obtener la señal, pero intente la misma configuración de software pero con esta otra NIC (probablemente deshabilite Broadcom si puede). Pruebe esto y vea cómo avanza, sé que lo que he descrito necesita un par de bits de hardware adicional, pero me imagino que su representante de IBM los prestará con gusto. Es la única forma de saberlo con certeza. Háganos saber lo que descubra, estoy realmente interesado si hay un problema con estas NIC, incluso si es un caso marginal extraño. Como comentario aparte, me reuniré con Intel y Broadcom la próxima semana para hablar sobre algo completamente no relacionado, pero ciertamente lo discutiré con ellos y les haré saber si encuentro algo de interés.

La pregunta sobre las interrupciones es cómo afectan el rendimiento general del sistema. Las interrupciones pueden evitar el procesamiento de la tierra del usuario y del kernel y, si bien es posible que no vea mucho uso de la CPU, se produce una gran cantidad de cambios de contexto y eso es un gran impacto en el rendimiento. Puede usar vmstaty verificar la systemcolumna, el csencabezado de las interrupciones y los cambios de contexto por segundo (las interrupciones incluyen el reloj, por lo que debe ponderar eso), también vale la pena comprobarlo.

La respuesta directa corta:

Si habilita el sondeo, reducirá los cambios de contexto (normalmente debido a interrupciones) de lo que sean ahora (15kips en su caso) a un número predeterminado (generalmente 1k a 2k).

Si actualmente tiene tráfico por encima del número predeterminado, entonces debería tener mejores tiempos de respuesta al habilitar el sondeo. Lo contrario también es cierto. No diría que esto es "necesario" a menos que los cambios de contexto afecten el rendimiento.

Para el seguimiento: con los módulos NAT y conntrack descargados más el conjunto de reglas minimizadas de iptables, obtenemos un excelente rendimiento. El equilibrador de carga IPVS ha realizado más de 900 Mbps / 150 kpps. Esto es mientras todavía se utilizan los mismos conjuntos de chips Broadcom bnx2.

Para concluir: el manejo de interrupciones parece estar bien y los valores predeterminados para Debian con el kernel 2.6.38 / 3.0.x parecen funcionar de manera aceptable.

Definitivamente preferiría usar las NIC de Intel para que podamos usar los paquetes estándar de Debian. Combatir el firmware bnx2 no libre ha sido una gran pérdida de tiempo.