18 votes

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

Quelqu'un dispose-t-il de données ou de calculs de base permettant de déterminer quand la coalescence des trames (NAPI) est nécessaire et quand une seule interruption par trame est suffisante ?

Mon matériel : IBM BladeServer HS22, matériel Broadcom 5709 Gigabit NIC (MSI-X), avec deux processeurs Xeon E5530 quad-core. L'objectif principal est le serveur proxy Squid. Le commutateur est un beau Cisco 6500 series.

Notre problème de base est qu'aux heures de pointe (trafic de 100 Mbps, seulement 10 000 pps), la latence et la perte de paquets augmentent. J'ai procédé à de nombreux réglages et à la mise à niveau du noyau vers la version 2.6.38, ce qui a permis d'améliorer la perte de paquets, mais la latence reste médiocre. Les pings sont sporadiques ; ils sautent même à 200 ms sur un réseau local Gbps. La réponse moyenne de Squid passe de 30 ms à plus de 500 ms, même si la charge CPU/mémoire est bonne.

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

Les NIC d'Intel semblent ne jamais avoir ce genre de problèmes, mais étant donné le système de lames et le matériel à configuration fixe, nous sommes en quelque sorte coincés avec les Broadcoms.

Tout indique que la carte réseau est la principale responsable. La meilleure idée que j'ai pour le moment est d'essayer de diminuer les interruptions tout en gardant une latence faible et un débit élevé.

Le bnx2 ne supporte malheureusement pas le rx ou le tx adaptatif.

El NAPI et interruptions adaptatives La réponse au fil de discussion fournit 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 coalescence ethtool pour une solution donnée. Existe-t-il une meilleure approche que le simple essai et l'erreur ?

La charge de travail et la configuration matérielle mentionnées ci-dessus ont-elles besoin de la NAPI ? Ou devrait-elle être capable de vivre avec une seule interruption par paquet ?

0 votes

Ce doit être une question difficile... Merci pour la prime, @Holocryptic ! J'ai essayé quelques réglages "ethtool -c" pour le coalescing mais pas de différences notables pour l'instant.

0 votes

Il n'y a pas de problème. Je l'ai juste vu s'attarder pendant quelques jours et il m'a semblé que c'était une bonne question. J'espère que quelqu'un aura quelque chose à vous proposer.

0 votes

Une autre mise à jour... nous sommes passés à des lames IBM HS23 avec des cartes d'interface réseau Emulex 10 Gbps. Cette semaine, nous avons atteint plus de 800 000 paquets/seconde, sans aucune chute. Nous avons dû faire beaucoup de réglages (ParcheandoLinux kernel drivers) pour équilibrer la charge des IRQs mais cela fonctionne fantastiquement maintenant.

6voto

DictatorBob Points 1594

Excellente question qui m'a poussé à faire quelques lectures pour essayer de comprendre. J'aimerais pouvoir dire que j'ai une réponse... mais peut-être quelques conseils.

Je peux au moins répondre à votre question, "devrait-il être capable de vivre sur une seule interruption par paquet". Je pense que la réponse est oui, en me basant sur un pare-feu très actif 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, le nombre de paquets par seconde est très élevé, et aucun réglage spécial d'ethtool n'a été effectué sur cette machine. Oh... un chipset Intel, par contre. :\\N-)

La seule chose qui a été faite était un équilibrage manuel de l'irq avec /proc/irq/XXX/smp_affinity, sur une base par interface. Je ne sais pas trop pourquoi ils ont choisi de procéder de cette manière plutôt que d'utiliser irqbalance, mais cela semble fonctionner.

J'ai également pensé aux calculs 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 données capturées vous devriez être en mesure de l'ajuster à un meilleur niveau.

Ceci étant dit, mon intuition me dit que vous êtes en quelque sorte lié au matériel ici... comme dans un firmware ou un bug interop d'une sorte.

0 votes

Quelques informations utiles ici : alexonlinux.com/

1 votes

Je suis d'accord avec l'affirmation de base "oui, il ne devrait pas y avoir de problèmes", mais étant donné qu'ils ont des problèmes, il est probable qu'il s'agisse d'un problème de firmware ou de pilote. Je n'ai pas du tout "réglé" ma station de travail et elle peut tirer 65kips sans transpirer ; 15kips ne devraient pas être un problème pour un CPU moderne. J'utilise exclusivement des cartes réseau Broadcom, la 5709 étant de loin la plus courante. Ce test a été effectué sous FreeBSD, pas sous Linux.

0 votes

Merci pour ces idées. J'ai essayé irqbalance mais je n'ai pas remarqué de différence. J'ai joué avec plus de paramètres coalesce (ethtool -c) mais je n'ai pas remarqué de différence. L'une des lames est en fait l'équilibreur de charge, poussant jusqu'à 120 000 paquets/seconde. J'ai remarqué que si les iptables NAT et conntrack sont chargés, l'utilisation du CPU de ksoftirqd atteint 100%. Sur les serveurs Squid (max 10 000 paquets/sec), j'ai effacé les 17 000 ( !!!) règles iptables et les latences ont immédiatement chuté. Je pensais avoir déjà essayé, mais apparemment non...

3voto

Chopper3 Points 99341

Compte tenu des capacités du processeur, du jeu de puces et du bus par rapport à la faible quantité de trafic que vous avez, 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-bit avec des NICs 10Gbps et leurs interruptions ne sont pas trop mauvaises du tout, ceci est 100 fois moins.

Il est évident que vous avez une configuration fixe (j'utilise les lames de HP qui sont assez similaires) et que remplacer les NICs par des 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 sur ce forum et ailleurs avec cette NIC Broadcom particulière. Les sites SE eux-mêmes ont eu des problèmes avec ce type d'incohérence et le remplacement par des cartes Intel a été très utile.

Ce que je vous recommande, c'est de choisir une seule lame et d'ajouter un adaptateur Intel à cette machine, vous devrez évidemment ajouter une interconnexion ou ce que IBM appelle ainsi pour faire sortir le signal, mais essayez la même configuration logicielle mais avec cette autre carte réseau (désactivez probablement le Broadcom si vous le pouvez). Testez cela et voyez comment vous vous en sortez, je sais que ce que j'ai décrit nécessite quelques éléments de matériel supplémentaire mais j'imagine que votre représentant IBM sera heureux de vous les prêter. C'est la seule façon d'être sûr. Tenez-nous au courant de vos découvertes, je suis sincèrement intéressé s'il y a un problème avec ces NICs, même si c'est un cas particulier. Pour l'anecdote, je rencontre Intel et Broadcom la semaine prochaine pour discuter de quelque chose qui n'a rien à voir, mais je ne manquerai pas d'en discuter avec eux et de vous faire savoir si je trouve quelque chose d'intéressant.

1voto

coredump Points 12455

La question qui se pose à propos des interruptions est de savoir comment elles influent sur les performances globales du système. Les interruptions peuvent préempter le traitement des terres de l'utilisateur et du noyau et, bien que l'utilisation du CPU ne soit pas très importante, il y a beaucoup de changements de contexte qui se produisent, ce qui a un impact important sur les performances. Vous pouvez utiliser vmstat et vérifiez le system colonne, cs pour les interruptions et les commutations de contexte par seconde (les interruptions incluent l'horloge, vous devez donc la pondérer), cela vaut également la peine de vérifier.

1voto

frameworkninja Points 628

La réponse courte et directe :

Si vous activez le polling, vous réduirez les commutations de contexte (normalement dues aux interupts) de ce qu'elles sont actuellement (15kips dans votre cas) à un nombre prédéterminé (généralement 1k à 2k).

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", sauf si les changements de contexte ont un impact sur les performances.

1voto

Wim Kerkhoff Points 911

Pour poursuivre : avec les modules NAT et conntrack déchargés et un jeu de règles iptables minimisé, nous obtenons des performances remarquables. L'équilibreur de charge IPVS a atteint plus de 900 Mbps / 150 kpps. Ceci en utilisant toujours 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 définitivement utiliser des cartes réseau Intel afin de pouvoir utiliser les paquets Debian standard. La lutte contre le micrologiciel non libre bnx2 a été une énorme perte de temps.

0 votes

Encore une mise à jour. Récemment, les performances se sont à nouveau dégradées sans raison apparente. Nous avons revu toutes les optimisations précédentes sans succès. Les cartes d'interface réseau Intel ne sont toujours pas une option économique (investissement de 30 à 40 000 dollars dans de nouvelles interconnexions, des commutateurs de 10 Go, etc.) MAIS, nous avons trouvé des lames IBM HS22 un peu plus récentes qui utilisent toujours le bnx2 pourri, mais avec un firmware plus récent. Les performances sont bien meilleures - nous avons franchi la barre des 150 000 paquets/seconde.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X