Pourquoi y a-t-il moins de latence sur le bouclage que sur une interface carpe?

Stack Overflow Careers est servi comme suit:

user -> internet -> our fw -> nginx -> haproxy -> web farm

FreeBSD est le système d'exploitation utilisé
aucun pare-feu ou QoS n'est en place sur cette boîte
nginx gère notre terminaison SSL
haproxy gère l'équilibrage de charge
nginx / haproxy poussent environ 15 Mbps dans chaque sens

Pendant le fonctionnement normal, nginx reçoit la requête HTTP, fait son travail et transmet la requête à une instance haproxy qui est liée à l'adresse de bouclage (127.0.0.1) sur cette même boîte.

Afin de résoudre certains problèmes l'autre jour, j'ai déplacé l'instance haproxy sur la même interface que nginx fonctionnait. Cela a immédiatement ajouté 100 ms de latence à toutes les demandes. Cette interface n'est pas une véritable interface physique, mais une interface carpe .

Quelqu'un peut-il m'expliquer pourquoi c'était le cas? Contention avec la file d'attente de paquets peut-être? Ou peut-être que le bouclage est toujours plus rapide parce qu'il est «doux»? Il y a quelque chose de fondamental qui me manque ici, et j'espère que quelqu'un va bien m'éduquer.

— Michael Gorsuch
source

Un paquet envoyé à une adresse sur-boîte, qu'il soit adressé via lo ou un port e {th, n}, ne frappe jamais le matériel sous Linux. Je ne peux pas parler avec autorité en ce qui concerne BSD, cependant.

— BMDan

Êtes-vous sûr de l'avoir basculé sur la même interface? Les 100 ms ont-ils disparu lorsque vous avez repassé l'haproxy en boucle?

— tomjedrz

@tomjedrz - oui. dès que je suis revenu, la latence avait disparu.

— Michael Gorsuch

Réponses:

Un délai constant de 100 ms semble étrange. Il semble que les paquets soient mis en mémoire tampon et ne soient pas immédiatement livrés. Ou peut-être que certains d'entre eux sont abandonnés et retransmis. Pouvez-vous exécuter tcpdump sur cette interface pour montrer le problème? Je ne sais pas comment fonctionne la pile IP sur FreeBSD, ni comment CARP est implémenté, mais serait-il possible par exemple que l'esclave annonce régulièrement son adresse MAC avec des ARP gratuits et que le maître envoie alternativement des paquets de chaque côté?

Pourriez-vous également exécuter tcpdump sur la véritable interface pour vous assurer que rien n'est émis?

Est-il possible que le système s'abstienne de mettre en cache l'entrée ARP d'un périphérique CARP, provoquant ainsi l'émission d'une demande ARP pour chaque paquet d'une session, à laquelle le démon CARP devrait répondre?

La plupart de ces idées sont stupides, mais c'est pour vous aider à chercher dans la bonne direction.

— Willy Tarreau
source

Merci pour les idées, Willy. Je ramène la configuration à l'interface en dehors des heures d'ouverture et vois ce qu'une trace de paquet apparaît.

— Michael Gorsuch

Pour plus de clarté, vous avez seulement changé la façon dont il était accédé, de l'adresse 127 à l'adresse IP locale; correct?

Si c'est le cas et que cela a fait une différence, quelque chose ne va pas. Vérifiez votre table de routage avec netstat -rnet voyez à quoi les adresses IP locales sont routées, elle doit être routée vers l'interface lo0 (tout comme 127).

Votre netstat -rnsortie devrait être vaguement similaire à ceci:

Internet:
Destination        Gateway            Flags    Refs      Use  Netif Expire
default            1.2.3.1            UGS       131  2655014   nge1
1.2.3.0/23         link#2             U           0       88   nge1
1.2.3.4            link#2             UHS         0    34848    lo0
127.0.0.1          link#5             UH          0    64678    lo0
192.168.0.0/26     link#1             U           2 41703537   nge0
192.168.0.1        link#1             UHS         0    70088    lo0

— Chris S
source

J'aurais dû inclure cela dans le post: ces interfaces sont des interfaces carpes. J'ai complètement glissé jusqu'à ce que je lance netstat. Cela fait-il une différence?

— Michael Gorsuch

Ouais, c'est tout. Si l'adresse que vous utilisez est affectée à une interface carpe utilisant cette IP, elle sera forcée à travers la pile carpe avant qu'elle n'atteigne le périphérique de bouclage; 100 ms seraient encore excessifs. L'hôte en question est-il le maître de cette adresse IP ou utilisez-vous l'équilibrage de charge? Il pourrait envoyer le trafic à l'autre hôte carpe.

— Chris S

L'hôte est le maître de cette IP.

— Michael Gorsuch

Je viens de terminer de fouetter un environnement similaire et de le tester. Je n'ai vu aucune différence appréciable dans les temps de réponse entre l'interface IP de la carpe, 127 IP et une IP physique. Je n'ai qu'un seul serveur à tester, donc pas d'esclaves carpes, mais je soupçonne que quelque chose ne va pas ailleurs dans votre environnement (pare-feu ou mise en forme du trafic?) Qui cause la latence. Il s'agit d'un i386-8.1-STABLE.

— Chris S

Merci, Chris. Je verrai si je peux rassembler plus d'informations lorsque le trafic diminue. Le système actuel n'utilise aucun package de pare-feu ni ne modifie le trafic. Je dois également noter (mettra à jour la question d'origine) que nous recevons une grande quantité de trafic en raison des offres d'emploi que nous affichons sur les sites de la famille SO. Nous nous déplaçons à environ 15 Mbps dans chaque sens pendant les heures normales.

— Michael Gorsuch

J'ai vu le bouclage implémenté comme un logiciel i / f de niveau d'interruption tel que le trafic ne sort jamais des sentiers battus. Cela aurait-il pu être le cas lorsque vous exécutiez un bouclage? Avertissement: Juste une question générale; Je ne connais rien à FreeBSD.

- pete

— Pete Wilson
source

Ce n'est pas ainsi que cela fonctionne dans FreeBSD.

— Chris S