Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

31.9. Éviter les conflits de verrouillage de la file d'attente d'écoute

La contention du verrouillage de la file d'attente peut entraîner des chutes de paquets et une utilisation accrue de l'unité centrale et, par conséquent, une latence plus élevée. Vous pouvez éviter la contention de la file d'attente de réception (RX) et de transmission (TX) en réglant votre application et en utilisant le pilotage des paquets de transmission.

Sur un système multicœur, vous pouvez améliorer les performances des applications de serveur réseau multithread si l'application ouvre le port en utilisant l'option de socket SO_REUSEPORT ou SO_REUSEPORT_BPF. Si l'application n'utilise pas l'une de ces options de socket, tous les threads sont obligés de partager un socket unique pour recevoir le trafic entrant. L'utilisation d'une seule socket provoque :

  • Contrainte importante sur la mémoire tampon de réception, ce qui peut entraîner des pertes de paquets et une utilisation accrue de l'unité centrale.
  • Augmentation significative de l'utilisation de l'unité centrale
  • Possiblement des chutes de paquets
lock contention
View larger image
lock contention

Avec l'option de socket SO_REUSEPORT ou SO_REUSEPORT_BPF, plusieurs sockets sur un hôte peuvent se lier au même port :

so reuseport
View larger image
so reuseport

Red Hat Enterprise Linux fournit un exemple de code sur l'utilisation des options de socket SO_REUSEPORT dans les sources du noyau. Pour accéder à l'exemple de code :

  1. Activer le référentiel rhel-9-for-x86_64-baseos-debug-rpms: 

    # subscription-manager repos --enable rhel-9-for-x86_64-baseos-debug-rpms
    Copy to Clipboard Toggle word wrap

  2. Installez le paquetage kernel-debuginfo-common-x86_64: 

    # dnf install kernel-debuginfo-common-x86_64
    Copy to Clipboard Toggle word wrap
  3. L'exemple de code est maintenant disponible dans le fichier /usr/src/debug/kernel-<version>/linux-<version>/tools/testing/selftests/net/reuseport_bpf_cpu.c fichier.

Dans les hôtes dotés d'un contrôleur d'interface réseau (NIC) qui prend en charge plusieurs files d'attente, la fonction XPS (transmit packet steering) répartit le traitement des paquets réseau sortants entre plusieurs files d'attente. Cela permet à plusieurs unités centrales de traiter le trafic réseau sortant et d'éviter les conflits de verrouillage des files d'attente de transmission et, par conséquent, les chutes de paquets.

Certains pilotes, tels que ixgbe, i40e, et mlx5 configurent automatiquement XPS. Pour savoir si le pilote prend en charge cette fonctionnalité, consultez la documentation de votre pilote de carte réseau. Consultez la documentation de votre pilote NIC pour savoir s'il prend en charge cette fonctionnalité. Si le pilote ne prend pas en charge le réglage automatique de XPS, vous pouvez affecter manuellement des cœurs de CPU aux files d'attente de transmission.

Note

Red Hat Enterprise Linux n'offre pas d'option permettant d'assigner de manière permanente les files d'attente de transmission aux cœurs de CPU. Utilisez les commandes dans un script et exécutez-le lorsque le système démarre.

Conditions préalables

  • Le NIC prend en charge plusieurs files d'attente.
  • Le paquet numactl est installé.

Procédure

  1. Affiche le nombre de files d'attente disponibles : 

    # ethtool -l enp1s0
Channel parameters for enp1s0:
Pre-set maximums:
RX:		0
TX:		0
Other:		0
Combined:	4
Current hardware settings:
RX:		0
TX:		0
Other:		0
Combined:	1
    Copy to Clipboard Toggle word wrap

    La section Pre-set maximums indique le nombre total de files d'attente et Current hardware settings le nombre de files d'attente actuellement affectées aux files d'attente de réception, de transmission, autres ou combinées.

  2. Facultatif : Si vous avez besoin de files d'attente sur des canaux spécifiques, attribuez-les en conséquence. Par exemple, pour affecter les 4 files d'attente au canal Combined, entrez : 

    # ethtool -L enp1s0 combined 4
    Copy to Clipboard Toggle word wrap

  3. Affiche le nœud NUMA (Non-Uniform Memory Access) auquel la carte d'interface réseau est affectée : 

    # cat /sys/class/net/enp1s0/device/numa_node
0
    Copy to Clipboard Toggle word wrap

    Si le fichier est introuvable ou si la commande renvoie -1, l'hôte n'est pas un système NUMA.

  4. Si l'hôte est un système NUMA, afficher quels CPU sont assignés à quel nœud NUMA : 

    # lscpu | grep NUMA
NUMA node(s):       2
NUMA node0 CPU(s):  0-3
NUMA node1 CPU(s):  4-7
    Copy to Clipboard Toggle word wrap

  5. Dans l'exemple ci-dessus, la carte d'interface réseau a 4 files d'attente et la carte d'interface réseau est assignée au nœud NUMA 0. Ce nœud utilise les cœurs de CPU 0-3. Par conséquent, mappez chaque file d'attente de transmission à l'un des cœurs de CPU de 0 à 3 : 

    # echo 1 > /sys/class/net/enp1s0/queues/tx-0/xps_cpus
# echo 2 > /sys/class/net/enp1s0/queues/tx-1/xps_cpus
# echo 4 > /sys/class/net/enp1s0/queues/tx-2/xps_cpus
# echo 8 > /sys/class/net/enp1s0/queues/tx-3/xps_cpus
    Copy to Clipboard Toggle word wrap

    Si le nombre de cœurs de CPU et de files d'attente de transmission (TX) est le même, utilisez un mappage 1 à 1 pour éviter toute forme de contention sur la file d'attente TX. Dans le cas contraire, si vous affectez plusieurs CPU à la même file d'attente TX, les opérations de transmission sur différents CPU entraîneront une contention du verrouillage de la file d'attente TX, ce qui aura un impact négatif sur le débit de transmission.

    Notez que vous devez transmettre le bitmap, qui contient les numéros de cœur du processeur, aux files d'attente. Utilisez la commande suivante pour calculer le bitmap : 

    # printf %x $((1 << <core_number> ))
    Copy to Clipboard Toggle word wrap

Vérification

  1. Identifier les identifiants de processus (PID) des services qui envoient du trafic : 

    # pidof <process_name>
12345 98765
    Copy to Clipboard Toggle word wrap

  2. Attachez les PID aux cœurs qui utilisent XPS : 

    # numactl -C 0-3 12345 98765
    Copy to Clipboard Toggle word wrap

  3. Surveillez le compteur requeues pendant que le processus envoie du trafic : 

    # tc -s qdisc
qdisc fq_codel 0: dev enp10s0u1 root refcnt 2 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64
 Sent 125728849 bytes 1067587 pkt (dropped 0, overlimits 0 requeues 30)
 backlog 0b 0p requeues 30
 ...
    Copy to Clipboard Toggle word wrap

    Si le compteur requeues n'augmente plus à un rythme significatif, il n'y a plus de conflit de verrouillage de la file d'attente TX.

Les applications qui utilisent le transfert de masse UDP à grande vitesse doivent activer et utiliser la fonction UDP Generic Receive Offload (GRO) sur la socket UDP. Cependant, vous pouvez désactiver GRO pour augmenter le débit si les conditions suivantes s'appliquent :

  • L'application ne prend pas en charge le GRO et la fonctionnalité ne peut pas être ajoutée.

  • Le débit TCP n'est pas pertinent.

    Avertissement

    La désactivation de GRO réduit considérablement le débit de réception du trafic TCP. Par conséquent, ne désactivez pas le GRO sur les hôtes où les performances TCP sont importantes.

Conditions préalables

  • L'hôte traite principalement le trafic UDP.
  • L'application n'utilise pas de GRO.
  • L'hôte n'utilise pas de protocoles de tunnel UDP, tels que VXLAN.
  • L'hôte n'exécute pas de machines virtuelles (VM) ni de conteneurs.

Procédure

  1. Optionnel : Afficher les profils de connexion de NetworkManager : 

    # nmcli connection show
NAME     UUID                                  TYPE      DEVICE
example  f2f33f29-bb5c-3a07-9069-be72eaec3ecf  ethernet  enp1s0
    Copy to Clipboard Toggle word wrap

  2. Désactiver la prise en charge du GRO dans le profil de connexion : 

    # nmcli connection modify example ethtool.feature-gro off
    Copy to Clipboard Toggle word wrap

  3. Réactiver le profil de connexion : 

    # nmcli connection up example
    Copy to Clipboard Toggle word wrap

Vérification

  1. Vérifiez que le GRO est désactivé : 

    # ethtool -k enp1s0 | grep generic-receive-offload
generic-receive-offload: off
    Copy to Clipboard Toggle word wrap
  2. Surveillez le débit du serveur. Réactiver le GRO dans le profil NetworkManager si le paramètre a des effets secondaires négatifs sur d'autres applications sur l'hôte.
Retour au début
Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2025 Red Hat