88 votos

¿Por qué es TCP aceptar() rendimiento tan malo bajo Xen?

La velocidad a la que mi servidor puede aceptar() de nuevo las conexiones TCP entrantes es realmente malo, bajo Xen. La misma prueba en metal desnudo de hardware muestra 3-5x velocidad de ups.

  1. ¿Cómo es que esto es tan malo bajo Xen?
  2. Se puede ajustar Xen para mejorar el rendimiento de las nuevas conexiones de TCP?
  3. Hay otras plataformas de virtualización más adecuado para este tipo de caso de uso?

De fondo

Últimamente he estado investigando algunos cuellos de botella de rendimiento de una casa desarrollada en Java server que se ejecuta bajo Xen. El servidor HTTP habla y respuestas simples de conexión de TCP/petición/respuesta/desconectar llamadas.

Pero incluso mientras que el envío de barcos cargados de tráfico en el servidor, no puede aceptar más de ~7000 conexiones TCP por segundo (en un 8-core a instancia de EC2, c1.xl ejecución de Xen). Durante la prueba, el servidor también exhiben un comportamiento extraño donde un núcleo (no necesariamente de la cpu 0) se pone muy cargado >80%, mientras que los otros núcleos de permanecer casi inactivo. Esto me lleva a pensar que el problema está relacionado con el núcleo subyacente/virtualización.

Cuando pruebas el mismo escenario en un metal desnudo, no una plataforma virtualizada puedo obtener los resultados de la prueba muestran TCP aceptar() de las tasas más de 35 000/segundo. Esta en un Core i5 de 4 núcleos de la máquina con Ubuntu con todos los núcleos casi completamente saturado. A mí ese tipo de figura parece correcto.

En el Xen instancia de nuevo, he intentado activar/ajustar casi todos los ajustes que hay en sysctl.conf. Incluida la habilitación de recepción de Paquetes de Dirección y Recibir el Flujo de Dirección y fijación de roscas/procesos de Cpu, pero sin aparentes avances.

Sé que degrada el rendimiento que se puede esperar cuando se ejecuta virtualizado. Pero a este grado? Un ritmo más lento, bare metal server superando virt. 8-core por un factor de 5?

  1. Es este realmente el comportamiento esperado de Xen?
  2. Se puede ajustar Xen para mejorar el rendimiento de las nuevas conexiones de TCP?
  3. Hay otras plataformas de virtualización más adecuado para este tipo de caso de uso?

La reproducción de este comportamiento

Cuando se profundiza en la investigación de este y detectar el problema me enteré de que la netperf herramienta de pruebas de rendimiento podría simular el escenario similar, yo estoy experimentando. El uso de netperf del TCP_CRR prueba que he recogido varios informes de diferentes servidores (tanto virtualizados y no virt.). Si te gustaría contribuir con algunos de los hallazgos o buscar mis informes actuales, por favor consulte https://gist.github.com/985475

¿Cómo sé que este problema no es debido a mal escrito el software?

  1. El servidor ha sido probado en bare metal de hardware y casi se satura todos los núcleos disponibles.
  2. Cuando el uso de keep-alive conexiones TCP, el problema desaparece.

¿Por qué es esto importante?

En ESN (mi empleador) yo soy el líder de proyecto de Beaconpush, un Cometa/Web Socket servidor escrito en Java. A pesar de que es muy eficiente y puede saturar casi cualquier ancho de banda dado, en condiciones óptimas, es todavía limitada a cómo rápidamente nuevas conexiones TCP se puede hacer. Es decir, si usted tiene un gran usuario churn donde los usuarios vienen y van muy a menudo, muchas conexiones TCP habrá que configurar/rasgado abajo. Tratamos de mitigar esta manteniendo conexiones con vida el mayor tiempo posible. Pero al final, el aceptar() el rendimiento es lo que mantiene a nuestros núcleos de spinning y no nos gusta que.


Actualización 1

Alguien ha publicado esta pregunta a Hacker News, hay algunas preguntas/respuestas. Pero voy a tratar de mantener esta pregunta actualizada con la información que me encuentro cuando voy.

Hardware/plataformas que he probado en:

  • EC2 con los tipos de instancias de c1.xl (8 núcleos, 7 GB de RAM) y cc1.4xlarge (2x Intel Xeon X5570, 23 GB de RAM). Ami utilizado fue ami-08f40561 y ami-1cad5275 respectivamente. Alguien también señaló que los "Grupos de Seguridad" (he.e EC2s firewall) puede afectar así. Pero para que este escenario de prueba, yo he probado sólo en localhost para eliminar los factores externos, tales como este. Otro rumor que he escuchado es que las instancias de EC2 no puede empujar más de 100k PPS.
  • Dos privados de servidor virtualizado ejecución de Xen. Uno tenía la carga cero antes de la prueba, pero no hacer una diferencia.
  • Privado dedicado, Xen-server en Rackspace. Sobre el mismo resultados.

Estoy en el proceso de re-ejecución de estas pruebas y el llenado de los informes en https://gist.github.com/985475 Si usted desea ayudar, de contribuir con sus números. Es fácil!

(El plan de acción se ha trasladado a una separada consolidada de la respuesta)

26voto

Jonathan Hanson Puntos 628

Ahora: un Pequeño paquete de rendimiento chupa bajo Xen

(movido de la pregunta en sí misma a una respuesta en su lugar)

De acuerdo a un usuario en HN (KVM desarrollador?) esto es debido a un pequeño paquete de rendimiento en Xen y también KVM. Es un problema conocido con la virtualización y, según él, de VMWare ESX se encarga de esto mucho mejor. También señaló que KVM están trayendo algunas nuevas características diseñadas aliviar este (post original).

Esta info es un poco desalentador si es correcta. De cualquier manera, voy a tratar de los siguientes pasos hasta que algunos de Xen gurú viene junto con una respuesta definitiva :)

Iain Kay de la xen-usuarios mailing list compilado este gráfico: netperf graph Aviso de la TCP_CRR bares, comparar "2.6.18-239.9.1.el5" vs "2.6.39 (con Xen 4.1.0)".

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

  1. Someter este asunto a un Xen-lista de correo específica y la xensource el bugzilla como sugiere syneticon-dj Un mensaje fue enviado a la xen-usuario de la lista, a la espera de respuesta.

  2. Crear un simple patológico, en el nivel de aplicación de casos de prueba y publicarlo.
    Un servidor de prueba con las instrucciones han sido creados y publicados a GitHub. Con esto, usted debería ser capaz de ver más del mundo real de casos de uso en comparación con netperf.

  3. Trate de 32 bits Xen PV instancia, como de 64 bits que podría ser la causa más sobrecarga en Xen. Alguien mencionó que este en HN. No hacer una diferencia.

  4. Trate de la habilitación de la red.ipv4.tcp_syncookies en sysctl.conf como se sugiere por abofh en HN. Al parecer, esto podría mejorar el rendimiento ya que el apretón de manos podría ocurrir en el núcleo. No he tenido suerte con este.

  5. Aumento de la acumulación de 1024 a algo mucho mayor, también sugerido por abofh en HN. Esto también puede ayudar, ya que los huéspedes podrían potencialmente aceptar() más conexiones durante la ejecución de la rebanada dada por el dom0 (el host).

  6. Compruebe que conntrack está deshabilitado en todas las máquinas, se puede reducir a la mitad el aceptar tasa (sugerido por deubeulyou). Sí, fue desactivado en todas las pruebas.

  7. De verificación para "escuchar la cola de desbordamiento y syncache cubos de desbordamiento en netstat-s" (sugerido por mike_esspe en HN).

  8. Dividir el manejo de la interrupción entre varios núcleos (RPS/RFS he intentado habilitar anterior se supone que para hacer esto, pero podría ser vale la pena intentarlo de nuevo). Sugerido por adamt en HN.

  9. La desactivación de descarga de segmentación TCP y scatter/gather aceleración como se sugiere por Matt Bailey. (No es posible en EC2 o similar VPS hosts)

20voto

Matt Bailey Puntos 191

Como anécdota, he encontrado que la desactivación de las NIC de la aceleración de hardware mejora en gran medida el rendimiento de la red en Xen controlador (también se cumple para LXC):

Dispersión accell:

/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 hipervisor de host. Usted tendrá que configurar esto para que lo apague en cada arranque. YMMV.

2voto

deubeulyou Puntos 121

Tal vez usted podría aclarar un poco - hizo ejecutar las pruebas bajo Xen en su propio servidor, o sólo en una instancia de EC2 ?

Aceptar es sólo otro syscall, y las nuevas conexiones son sólo diferentes en que los primeros paquetes de tener algunos indicadores específicos - un hipervisor como Xen definitivamente no veo ninguna diferencia. Otras partes de su programa de instalación: en EC2, por ejemplo, no me sorprendería si los Grupos de Seguridad tenido algo que ver con ella; conntrack también se informó de reducir a la mitad las nuevas conexiones aceptar tasa (PDF).

Por último, parece ser que hay CPU/Kernel combinaciones que causa raro el uso de la CPU / retrasos en EC2 (y probablemente Xen en general), como escribió en su blog acerca de por Librato recientemente.

0voto

kupson Puntos 1701

Asegúrese de movilidad iptables y otros ganchos en la reducción de código en el dom0. Obviamente, esto sólo se aplica a puente de red de configuración de Xen.

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 de el tamaño de el servidor, pero en los más pequeños (4-core) dedicar un núcleo de la cpu para dom0 y el pin. El hipervisor de las opciones de arranque:

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

¿Has probado a pasar físico ethernet PCI dispositivo a domU? No debe ser agradable mejora en el rendimiento.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: