Quelles charges réseau nécessitent une interrogation NIC par rapport aux interruptions?

Quelqu'un a-t-il des données ou des calculs de base qui peuvent répondre lorsque la fusion de trames (NAPI) est requise et lorsqu'une seule interruption par trame est suffisante?

Mon matériel: IBM BladeServer HS22, matériel Broadcom 5709 Gigabit NIC (MSI-X), avec deux processeurs quadricœurs Xeon E5530. Le but principal est le serveur proxy Squid. Le commutateur est une belle série Cisco 6500.

Notre problème de base est que pendant les périodes de pointe (100 Mbps de trafic, seulement 10 000 pps), la latence et la perte de paquets augmentent. J'ai fait beaucoup de réglages et de mise à niveau du noyau vers 2.6.38 et cela a amélioré la perte de paquets mais la latence est toujours médiocre. Les pings sont sporadiques; sautant même à 200 ms sur le LAN local Gbps. La réponse moyenne de Squid passe de 30 ms à 500 + ms même si la charge CPU / mémoire est correcte.

Les interruptions grimpent à environ 15 000 / seconde pendant le pic. Ksoftirqd n'utilise pas beaucoup de CPU; J'ai installé irqbalance pour équilibrer les IRQ (8 pour eth0 et eth1) sur tous les cœurs, mais cela n'a pas beaucoup aidé.

Les cartes réseau Intel ne semblent jamais avoir ce genre de problèmes, mais en raison du système de lames et du matériel de configuration fixe, nous sommes en quelque sorte coincés avec les Broadcom.

Tout indique que la carte réseau est le principal coupable. La meilleure idée que j'ai en ce moment est d'essayer de diminuer les interruptions tout en maintenant à la fois une latence faible et un débit élevé.

Le bnx2 ne prend malheureusement pas en charge l'adaptive-rx ou le tx.

La réponse du thread NAPI vs Adaptive Interrupts offre une excellente vue d'ensemble de la modération des interruptions, mais aucune information concrète sur la façon de calculer les paramètres optimaux de fusion ethtool pour une solution de contournement donnée. Existe-t-il une meilleure approche que des essais et erreurs?

La charge de travail et la configuration matérielle mentionnées ci-dessus ont-elles même besoin de NAPI? Ou devrait-il pouvoir vivre sur une seule interruption par paquet?

Grande question qui m'a fait faire de la lecture pour essayer de le comprendre. J'aimerais pouvoir dire que j'ai une réponse ... mais peut-être quelques indices.

Je peux au moins répondre à votre question, "devrait-il pouvoir vivre sur une seule interruption par paquet". Je pense que la réponse est oui, sur la base d'un pare-feu très occupé auquel j'ai accès:

Sortie 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

Comme vous pouvez le voir, certains paquets très élevés par seconde comptent, et aucun ajustement spécial d'ethtool n'a été effectué sur cette machine. Oh ... le chipset Intel, cependant. : \

La seule chose qui a été faite a été un équilibrage manuel de l'irq avec / proc / irq / XXX / smp_affinity, interface par interface. Je ne sais pas pourquoi ils ont choisi de suivre cette voie plutôt qu'avec un déséquilibre, mais cela semble fonctionner.

J'ai aussi pensé aux mathématiques nécessaires pour répondre à votre question, mais je pense qu'il y a beaucoup trop de variables. Donc ... pour résumer, à mon avis, la réponse est non, je ne pense pas que vous puissiez prédire les résultats ici, mais avec suffisamment de capture de données, vous devriez pouvoir l'ajuster à un meilleur niveau.

Cela dit, je pense que vous êtes en quelque sorte lié au matériel ici ... comme dans un micrologiciel ou un bug d'interopérabilité.

Compte tenu des capacités du processeur, du chipset et du bus par rapport à un trafic aussi faible, il n'y a aucune raison pour que vous ayez besoin d'une forme quelconque de gestion des interruptions. Nous avons plusieurs machines RHEL 5.3 64 bits avec des cartes réseau 10 Gbit / s et leurs interruptions ne sont pas trop mauvaises, c'est 100 fois moins.

De toute évidence, vous avez une configuration fixe (j'utilise des lames HP qui sont assez similaires), donc l'échange de cartes réseau pour Intels est maintenant une option facile, mais ce que je dirais, c'est que je commence à repérer un certain nombre de problèmes similaires autour de ce forum et ailleurs avec cette carte réseau Broadcom particulière. Jamais les sites SE eux-mêmes ont eu des problèmes avec ce type d'incohérence et le passage aux cartes réseau Intel a absolument aidé.

Ce que je recommanderais, c'est de choisir une seule lame et d'ajouter un adaptateur basé sur Intel à cette machine, vous devrez évidemment ajouter une interconnexion ou tout autre appel IBM pour obtenir le signal, mais essayez la même configuration logicielle, mais avec cet autre NIC (désactivez probablement Broadcom si vous le pouvez). Testez cela et voyez comment vous vous en sortez, je sais que ce que j'ai décrit a besoin de quelques morceaux de matériel supplémentaire, mais j'imagine que votre représentant IBM vous les prêtera avec plaisir. C'est la seule façon de savoir avec certitude. S'il vous plaît laissez-nous savoir ce que vous découvrez, je suis vraiment intéressé s'il y a un problème avec ces cartes réseau, même si c'est un cas de bord étrange. En aparté, je rencontre Intel et Broadcom la semaine prochaine pour discuter de quelque chose de complètement indépendant, mais je vais certainement en discuter avec eux et vous faire savoir si je trouve quelque chose d'intéressant.

La question des interruptions concerne leur impact sur les performances globales du système. Les interruptions peuvent préempter le traitement des terres des utilisateurs et du noyau et même si vous ne voyez pas beaucoup d'utilisation du processeur, il y a beaucoup de changements de contexte qui se produisent et c'est un gros coup de performances. Vous pouvez utiliser vmstatet vérifier la systemcolonne, l'en- cstête pour les interruptions et les changements de contexte par seconde (les interruptions incluent l'horloge, vous devez donc les pondérer), cela vaut également la peine d'être vérifié.

La réponse directe courte:

Si vous activez l'interrogation, vous réduirez les changements de contexte (normalement en raison d'interruptions) de ce qu'ils sont maintenant (15 kips dans votre cas) à un nombre prédéterminé (généralement de 1 000 à 2 000).

Si vous avez actuellement un trafic supérieur au nombre prédéterminé, vous devriez avoir de meilleurs temps de réponse en activant l'interrogation. L'inverse est également vrai. Je ne dirais pas que c'est "nécessaire" à moins que les changements de contexte n'affectent les performances.

Pour le suivi: avec les modules NAT et conntrack déchargés et l'ensemble de règles iptables minimisé, nous obtenons des performances exceptionnelles. L'équilibreur de charge IPVS a fait plus de 900 Mbps / 150 kpps. Ceci tout en utilisant les mêmes chipsets Broadcom bnx2.

Donc pour conclure: la gestion des interruptions semble correcte et les valeurs par défaut pour Debian avec le noyau 2.6.38 / 3.0.x semblent fonctionner de manière acceptable.

Je préférerais certainement utiliser des cartes réseau Intel afin que nous puissions utiliser des paquets Debian standard. La lutte contre le micrologiciel bnx2 non libre a été une énorme perte de temps.