Pregunta ¿Por qué es tan malo el rendimiento de TCP accept () en Xen?


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 3-5x aceleraciones.

  1. ¿Cómo es que esto es tan malo bajo 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 caso de uso?

Fondo

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

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

Al probar el mismo escenario en una plataforma no virtualizada y sin metal, obtengo resultados de prueba que muestran tasas de aceptación () de TCP superiores a 35 000 / segundo. Esto en una máquina Core i5 4 que ejecuta Ubuntu con todos los núcleos casi completamente saturados. Para mí, ese tipo de figura parece correcto.

En la instancia de Xen de nuevo, he intentado habilitar / modificar casi todas las configuraciones en sysctl.conf. Incluyendo habilitar Recibir paquete de dirección y Recibir dirección de flujo y la fijación de subprocesos / procesos a las CPU, pero sin ganancias aparentes.

Sé que el rendimiento degradado es de esperar cuando se ejecuta virtualizado. Pero a este grado? Un servidor más lento, sin metal, superando a 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 caso de uso?

Reproduciendo este comportamiento

Cuando seguí investigando esto y localizando el problema, descubrí que el netperf herramienta de prueba de rendimiento podría simular el escenario similar que estoy experimentando. Usando la prueba TCP_CRR de netperf, he recopilado varios informes de diferentes servidores (virtualizados y no válidos). 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 se ha probado en hardware sin protección y casi satura todos los núcleos disponibles.
  2. Cuando se usan conexiones TCP de mantener vivo, el problema desaparece.

¿Porque es esto importante?

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


Actualización 1

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

Hardware / plataformas he probado esto en:

  • EC2 con 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, solo he intentado en localhost eliminar factores externos como este. Otro rumor que he escuchado es que las instancias de EC2 no pueden impulsar más de 100k PPS.
  • Dos servidores privados virtualizados ejecutando Xen. Uno tenía carga cero antes de la prueba, pero no hizo una diferencia.
  • Privado dedicado, Xen-server 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 quieres ayudar, contribuye con tus números. ¡Es fácil!

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


87
2018-05-22 16:39


origen


Excelente trabajo para identificar un problema, pero creo que le servirían mucho mejor en una lista de correo específica de Xen, un foro de soporte o incluso sitio de informe de error xensource. Creo que esto podría ser un error del programador: si tomas tu número de 7.000 conexiones * 4 núcleos / 0,80 de carga de CPU, obtendrás exactamente 35,000, el número que obtendrías cuando 4 núcleos estuvieran completamente saturados. - the-wabbit
Ah, y una cosa más: pruebe una versión de kernel diferente (quizás más reciente) para su invitado, si puede. - the-wabbit
@ syneticon-dj Gracias. Lo probé en un cc1.4xlarge en EC2 con el kernel 2.6.38. Vi alrededor de un aumento de ~ 10% si no me equivoco. Pero es más probable debido al hardware más robusto de ese tipo de instancia. - cgbystrom
Gracias por mantener esto actualizado con las respuestas de la HN, es una gran pregunta. Sugiero mover el plan de acción a una respuesta consolidada, posiblemente, ya que estas son todas las respuestas posibles al problema. - Jeff Atwood
@jeff Mueve el plan de acción, revisa. - cgbystrom


Respuestas:


En este momento: el rendimiento de paquetes pequeños apesta bajo Xen

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

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, el ESX de VMWare se maneja mucho mejor. También señaló que KVM está trayendo algunas características nuevas diseñadas para aliviar esto (post original).

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

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

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

  1. Envía este problema a una lista de correo específica de Xen y al bugzilla del xensource como lo sugiere syneticon-dj UNA mensaje fue publicado en la lista de usuarios xen, esperando respuesta.

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

  3. Pruebe con una instancia de invitado de PV Xen de 32 bits, ya que 64 bits pueden causar más sobrecarga en Xen. Alguien mencionó esto en HN. No hizo una diferencia.

  4. Intente habilitar net.ipv4.tcp_syncookies en sysctl.conf como lo sugiere abofh en HN. Esto aparentemente podría mejorar el rendimiento ya que el apretón de manos ocurriría en el kernel. 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 aceptar () más conexiones durante su segmento de ejecución dado por dom0 (el host).

  6. Verifique 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í, fue desactivado en todas las pruebas.

  7. Verifique el "desbordamiento de la cola de escucha y el desbordamiento de los cubos de sincronización en netstat -s" (sugerido por mike_esspe en HN).

  8. Dividir el manejo de interrupciones entre múltiples núcleos (se supone que RPS / RFS intenté habilitarlo antes, pero vale la pena intentarlo de nuevo). Sugerido por adamt en HN.

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


26
2018-05-22 23:41



+1 ¡Definitivamente publica los resultados de rendimiento cuando te hayas enterado! - chrisaycock
Alguien me empujó en Twitter con respecto a esta pregunta. Lamentablemente, parece que estos problemas persisten. No he investigado mucho desde el año pasado. Xen pudo haber mejorado durante este tiempo, no lo sé. El desarrollador de KVM también mencionó que estaban abordando problemas como este. Podría valer la pena seguir. Además, otra recomendación que he escuchado es probar OpenVZ en lugar de Xen / KVM, ya que agrega menos o ninguna intercepción / intercepción de syscalls. - cgbystrom


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

Dispersión de acumulación-aceleración:

/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 configurarlo para apagarlo en cada arranque. YMMV.


20
2018-05-22 19:09



Secundo esto. Tenía un servidor Windows 2003 ejecutándose en Xen que sufrió algunos problemas horribles de pérdida de paquetes en condiciones de alto rendimiento. El problema desapareció cuando deshabilité la descarga del segmento TCP - rupello
Gracias. Actualicé el "plan de acción" en la pregunta original con sus sugerencias. - cgbystrom
ver también cloudnull.io/2012/07/xenserver-network-tuning - Lari Hotari


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

Aceptar es solo otro syscall, y las nuevas conexiones son diferentes en 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; conntrack también es informó a la mitad de nuevas conexiones acepta tasa (PDF).

Por último, parece que hay combinaciones de CPU / Kernel que causan un uso extraño de CPU / cuelgues en EC2 (y probablemente Xen en general), como Publicado recientemente por Librato.


2
2018-05-22 19:56



Actualicé la pregunta y aclaré en qué hardware probé esto. abofh también sugirió aumentar la acumulación de pedidos más allá de 1024 para acelerar el número de posibles aceptaciones () durante una porción de ejecución para el invitado. Con respecto a Conntrack, definitivamente debería verificar que tales cosas estén deshabilitadas, gracias. He leído ese artículo de Liberato, pero dada la cantidad de hardware diferente que probé, no debería ser así. - cgbystrom


Asegúrese de que ha desactivado 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 puentes.

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 de los más pequeños (procesador de 4 núcleos) dedica un núcleo de cpu a Xen dom0 y fíjalo. Opciones de arranque del hipervisor:

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

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


0
2018-02-11 11:35