La velocidad a la que mi servidor puede aceptar () nuevas conexiones TCP entrantes es realmente mala en Xen. La misma prueba en hardware de metal desnudo muestra aceleraciones de 3-5x.

1. ¿Cómo es que esto es tan malo con Xen?
2. ¿Puedes ajustar Xen para mejorar el rendimiento de las nuevas conexiones TCP?
3. ¿Existen otras plataformas de virtualización más adecuadas para este tipo de casos de uso?

Antecedentes

Últimamente he estado investigando algunos cuellos de botella de rendimiento de un servidor Java desarrollado internamente que se ejecuta bajo Xen. El servidor habla HTTP y responde llamadas simples de conexión / solicitud / respuesta / desconexión de TCP.

Pero incluso mientras envía cargas de tráfico al servidor, no puede aceptar más de ~ 7000 conexiones TCP por segundo (en una instancia EC2 de 8 núcleos, c1.xlarge ejecuta Xen). Durante la prueba, el servidor también exhibe un comportamiento extraño en el que un núcleo (no necesariamente CPU 0) se carga mucho> 80%, mientras que los otros núcleos permanecen casi inactivos. Esto me lleva a pensar que el problema está relacionado con el núcleo / virtualización subyacente.

Cuando pruebo el mismo escenario en una plataforma no virtualizada de metal desnudo, obtengo resultados de prueba que muestran tasas de aceptación de TCP () más allá de 35 000 / segundo. Esto en una máquina Core i5 4 core que ejecuta Ubuntu con todos los núcleos casi completamente saturados. Para mí, ese tipo de figura parece correcta.

En la instancia de Xen nuevamente, he intentado habilitar / ajustar casi todas las configuraciones que hay en sysctl.conf. Incluyendo la habilitación de Recibir Packet Steering y Recibir Flow Steering y fijar hilos / procesos a las CPU pero sin ganancias aparentes.

Sé que es de esperar un rendimiento degradado cuando se ejecuta virtualizado. Pero a este grado? Un servidor más lento y básico que supera al virt. 8 núcleos por un factor de 5?

1. ¿Es este el comportamiento realmente esperado de Xen?
2. ¿Puedes ajustar Xen para mejorar el rendimiento de las nuevas conexiones TCP?
3. ¿Existen otras plataformas de virtualización más adecuadas para este tipo de casos de uso?

Reproduciendo este comportamiento

Al investigar más a fondo y determinar el problema, descubrí que la herramienta de prueba de rendimiento de netperf podría simular el escenario similar que estoy experimentando. Utilizando la prueba TCP_CRR de netperf, he recopilado varios informes de diferentes servidores (tanto virtualizados como no virtuales). Si desea contribuir con algunos hallazgos o consultar mis informes actuales, consulte https://gist.github.com/985475

¿Cómo sé que este problema no se debe a un software mal escrito?

1. El servidor ha sido probado en hardware de metal desnudo y casi satura todos los núcleos disponibles.
2. Cuando se usan conexiones TCP para mantener vivo, el problema desaparece.

¿Porque es esto importante?

En ESN (mi empleador) soy el líder del proyecto de Beaconpush , un servidor Comet / Web Socket escrito en Java. Aunque es muy eficiente y puede saturar casi cualquier ancho de banda que se le otorgue en condiciones óptimas, todavía se limita a la rapidez con la que se pueden hacer nuevas conexiones TCP. Es decir, si tiene una gran rotación de usuarios donde los usuarios van y vienen muy a menudo, muchas conexiones TCP tendrán que configurarse / desglosarse. Intentamos mitigar esto manteniendo las conexiones vivas el mayor tiempo posible. Pero al final, el rendimiento accept () es lo que evita que nuestros núcleos giren y eso no nos gusta.

Actualización 1

Alguien publicó esta pregunta en Hacker News , también hay algunas preguntas / respuestas allí. Pero intentaré mantener esta pregunta actualizada con la información que encuentre a medida que avance.

Hardware / plataformas He probado esto en:

• EC2 con los tipos de instancia c1.xlarge (8 núcleos, 7 GB de RAM) y cc1.4xlarge (2x Intel Xeon X5570, 23 GB de RAM). Los AMI utilizados fueron ami-08f40561 y ami-1cad5275 respectivamente. Alguien también señaló que los "Grupos de seguridad" (es decir, el firewall de EC2) también podrían afectar. Pero para este escenario de prueba, he intentado solo en localhost para eliminar factores externos como este. Otro rumor que escuché es que las instancias de EC2 no pueden impulsar más de 100k PPS.
• Dos servidores virtualizados privados que ejecutan Xen. Uno tenía cero carga antes de la prueba, pero no hizo la diferencia.
• Privado dedicado, servidor Xen en Rackspace. Sobre los mismos resultados allí.

Estoy en el proceso de volver a ejecutar estas pruebas y completar los informes en https://gist.github.com/985475. Si desea ayudar, contribuya con sus números. ¡Es fácil!

(El plan de acción se ha movido a una respuesta separada y consolidada)

En este momento: el rendimiento de paquetes pequeños es un asco bajo Xen

(movido de la pregunta en sí a una respuesta separada)

Según un usuario de HN (¿un desarrollador de KVM?), Esto se debe al pequeño rendimiento del paquete en Xen y también en KVM. Es un problema conocido con la virtualización y, según él, VMware ESX maneja esto mucho mejor. También señaló que KVM está trayendo algunas nuevas características diseñadas para aliviar esto ( publicación original ).

Esta información es un poco desalentadora si es correcta. De cualquier manera, intentaré los pasos a continuación hasta que aparezca un gurú de Xen con una respuesta definitiva :)

Iain Kay de la lista de correo xen-users compiló este gráfico: Observe las barras TCP_CRR, compare "2.6.18-239.9.1.el5" frente a "2.6.39 (con Xen 4.1.0)".

Plan de acción actual basado en respuestas / respuestas aquí y de HN :

1. Envíe este problema a una lista de correo específica de Xen y al bugzilla de xensource como sugiere syneticon-dj. Se envió un mensaje a la lista de usuarios de xen , esperando respuesta.

2. Cree un caso de prueba patológico simple a nivel de aplicación y publíquelo.
   Se ha creado y publicado un servidor de prueba con instrucciones en GitHub . Con esto, debería poder ver un caso de uso más real en comparación con netperf.

3. Pruebe una instancia de invitado de PV Xen de 32 bits, ya que 64 bits podría estar causando más sobrecarga en Xen. Alguien mencionó esto en HN. No hizo la diferencia.

4. Intente habilitar net.ipv4.tcp_syncookies en sysctl.conf como lo sugiere abofh en HN. Aparentemente, esto podría mejorar el rendimiento ya que el apretón de manos ocurriría en el núcleo. No tuve suerte con esto.

5. Aumente el retraso de 1024 a algo mucho más alto, también sugerido por abofh en HN. Esto también podría ayudar, ya que el invitado podría potencialmente aceptar () más conexiones durante su segmento de ejecución dado por dom0 (el host).

6. Vuelva a verificar que conntrack esté desactivado en todas las máquinas, ya que puede reducir a la mitad la tasa de aceptación (sugerido por deubeulyou). Sí, se deshabilitó en todas las pruebas.

7. Verifique "desbordamiento de cola de escucha y desbordamiento de cubos de sincache en netstat -s" (sugerido por mike_esspe en HN).

8. Divida el manejo de interrupciones entre múltiples núcleos (RPS / RFS que intenté habilitar anteriormente se supone que deben hacer esto, pero podría valer la pena intentarlo nuevamente). Sugerido por adamt en HN.

9. Desactivar la descarga de segmentación de TCP y la aceleración de dispersión / recopilación como lo sugiere Matt Bailey. (No es posible en hosts EC2 o VPS similares)

Como anécdota, descubrí que desactivar la aceleración de hardware de NIC mejora enormemente el rendimiento de la red en el controlador Xen (también es cierto para LXC):

Acceso disperso-reunido:

/usr/sbin/ethtool -K br0 sg off

Descarga de segmentación TCP:

/usr/sbin/ethtool -K br0 tso off

Donde br0 es su puente o dispositivo de red en el host del hipervisor. Tendrá que configurar esto para apagarlo en cada arranque. YMMV.

Tal vez podría aclarar un poco: ¿ejecutó las pruebas bajo Xen en su propio servidor, o solo en una instancia EC2?

Aceptar es solo otra llamada al sistema, y ​​las nuevas conexiones solo son diferentes, ya que los primeros paquetes tendrán algunos indicadores específicos: un hipervisor como Xen definitivamente no debería ver ninguna diferencia. Otras partes de su configuración podrían: en EC2, por ejemplo, no me sorprendería si los Grupos de Seguridad tuvieran algo que ver con eso; También se informa que conntrack reduce a la mitad la tasa de aceptación de nuevas conexiones (PDF) .

Por último, parece que hay combinaciones de CPU / Kernel que causan el uso / interrupciones de CPU extrañas en EC2 (y probablemente Xen en general), según lo publicado recientemente por Librato .

Asegúrese de deshabilitar iptables y otros enlaces en el código de puente en dom0. Obviamente, solo se aplica a la configuración de Xen de redes de puente.

echo 0 > /proc/sys/net/bridge/bridge-nf-call-ip6tables
echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables
echo 0 > /proc/sys/net/bridge.bridge-nf-call-arptables

Depende del tamaño del servidor, pero los más pequeños (procesador de 4 núcleos) dedican un núcleo de CPU a Xen dom0 y lo fijan. Opciones de arranque del hipervisor:

dom0_max_vcpus=1 dom0_vcpus_pin dom0_mem=<at least 512M>

¿Intentaste pasar un dispositivo PCI físico de Ethernet a domU? Debería haber un buen aumento de rendimiento.