Rendimiento del bucle de retorno de Linux con TCP_NODELAY habilitado

Question

Recientemente me encontré con un problema de rendimiento de TCP interesante mientras ejecutaba algunas pruebas de rendimiento que comparaban el rendimiento de la red con el rendimiento del bucle invertido. En mi caso, el rendimiento de la red excedió el rendimiento del bucle invertido (red 1Gig, misma subred). En el caso que estoy tratando, las latencias son cruciales, entonces TCP_NODELAY está habilitado. La mejor teoría que hemos encontrado es que el control de congestión TCP está reteniendo paquetes. Hicimos algunos análisis de paquetes y definitivamente podemos ver que los paquetes se están reteniendo, pero la razón no es obvia. Ahora las preguntas ...

1) ¿En qué casos, y por qué, la comunicación a través del loopback sería más lenta que en la red?

2) Al enviar lo más rápido posible, ¿por qué alternar TCP_NODELAY tiene un impacto mucho mayor en el rendimiento máximo sobre el bucle invertido que en la red?

3) ¿Cómo podemos detectar y analizar el control de congestión TCP como una posible explicación del bajo rendimiento?

4) ¿Alguien tiene alguna otra teoría sobre el motivo de este fenómeno? Si es así, ¿algún método para probar la teoría?

Aquí es algunos datos de muestra generados por un simple punto a punto C++ aplicación:

 
Transport  Message Size (bytes) TCP NoDelay Send Buffer (bytes) Sender Host Receiver Host Throughput (bytes/sec) Message Rate (msgs/sec) 
TCP   128     On   16777216    HostA   HostB   118085994    922546 
TCP   128     Off   16777216    HostA   HostB   118072006    922437 
TCP   128     On    4096    HostA   HostB   11097417     86698 
TCP   128     Off    4096    HostA   HostB   62441935    487827 
TCP   128     On   16777216    HostA   HostA   20606417    160987 
TCP   128     Off   16777216    HostA   HostA   239580949    1871726 
TCP   128     On    4096    HostA   HostA   18053364    141041 
TCP   128     Off    4096    HostA   HostA   214148304    1673033 
UnixStream 128     -    16777216    HostA   HostA   89215454    696995 
UnixDatagram 128     -    16777216    HostA   HostA   41275468    322464 
NamedPipe  128     -    -      HostA   HostA   73488749    574130 

Éstos son algunos más piezas de información útil:

• única que veo este problema con una pequeña mensajes
• HostA y HostB tienen el mismo kit de hardware (Xeon X5550@2.67GHz, 32 núcleos en total/128 Gig Mem/1Gig Nics)
• OS es RHEL 5.4 kernel 2.6.18-164.2.1.el5)

Gracias

Answer 1

1 o 2) no estoy seguro de por qué está molestando a utilizar bucle de retorno en absoluto, yo personalmente no sé qué tan cerca se parecerá a una interfaz real y qué tan válida será. Sé que Microsoft deshabilita NAGLE para la interfaz de bucle invertido (si le importa). Eche un vistazo al this link, hay una discusión sobre esto.

3) Revisaré de cerca los primeros paquetes en ambos casos y veré si está recibiendo un retraso severo en los primeros cinco paquetes. Ver here

Answer 2

1) ¿En qué casos, y por qué, la comunicación a través del loopback sería más lenta que en la red?

Loopback pone el paquete setup + tcp chksum para ambos tx + rx en la misma máquina, por lo que necesita hacer 2 veces más procesamiento, mientras que con 2 máquinas divide el tx/rx entre ellos. Esto puede tener un impacto negativo en el loopback.

2) Al enviar lo más rápido posible, ¿por qué no alternar TCP_NODELAY tienen mucho más de un impacto en el rendimiento máximo por encima de bucle de retorno que sobre la red?

No estoy seguro de cómo ha llegado a esta conclusión, pero la red loopback vs se implementa de manera muy diferente, y si trata de llevarlos al límite, tendrá problemas diferentes.Las interfaces de bucle invertido (como se menciona en la respuesta a 1) provocan una sobrecarga de procesamiento de tx + rx en la misma máquina. Por otro lado, los NIC tienen un # de límites en términos de cuántos paquetes sobresalientes pueden tener en sus búferes circulares, etc., lo que causará cuellos de botella completamente diferentes (y esto también varía mucho de un chip a otro, e incluso del interruptor que está entre ellos)

3) ¿Cómo podemos detectar y analizar el control de congestión TCP como una posible explicación del bajo rendimiento?

El control de congestión solo se inicia si hay pérdida de paquetes. ¿Estás viendo la pérdida de paquetes? De lo contrario, probablemente esté alcanzando límites en el tamaño de la ventana tcp frente a los factores de latencia de la red.

4) ¿Alguien tiene alguna otra teoría sobre el motivo de este fenómeno? Si es así, ¿algún método para probar la teoría?

No entiendo el fenómeno al que se refiere aquí. Todo lo que veo en su mesa es que tiene algunos zócalos con un gran búfer de envío, esto puede ser perfectamente legítimo. En una máquina rápida, su aplicación será capaz de generar más datos de los que la red puede bombear, por lo que no estoy seguro de lo que está clasificando como un problema aquí.

Una nota final: mensajes pequeños crean un rendimiento mucho mayor éxito en la red, por diversas razones, tales como:

• hay una fija por encima de la cabeza de paquetes (para los encabezados + IP + TCP mac), y cuanto menor es la carga útil, más gastos generales tendrá.
• muchas limitaciones de NIC son relativas al # de paquetes sobresalientes, lo que significa que golpeará cuellos de botella de NIC con mucha menos información cuando use paquetes más pequeños.
• la red en sí misma como sobrecarga por paquete, por lo que la cantidad máxima de datos que puede bombear a través de la red depende del tamaño de los paquetes de nuevo.

Answer 3

El es el mismo problema al que me enfrenté, también. Al transferir 2 MB de datos entre dos componentes que se ejecutan en la misma máquina RHEL6, tardó 7 segundos en completarse. Cuando el tamaño de los datos es grande, el tiempo no es aceptable. Se tardó 1 minuto en transferir 10 MB de datos.

Luego he intentado con TCP_NODELAY deshabilitado. Resolvió el problema

Esto no ocurre cuando los dos componentes están en dos máquinas diferentes.