Problema de rendimiento de socket TCP/IP de Java

Question

Nuestra aplicación está leyendo datos muy rápido a través de zócalos TCP/IP en Java. Estamos utilizando la biblioteca NIO con Sockets y Selector sin bloqueo para indicar que está listo para leer. En promedio, los tiempos generales de procesamiento para leer y manejar los datos leídos son de menos de milisegundos. Sin embargo, con frecuencia vemos picos de 10-20 milisegundos. (corriendo en Linux).

Usando tcpdump podemos ver la diferencia de tiempo entre la lectura de tcpdump de 2 mensajes discretos, y comparar eso con el tiempo de nuestras aplicaciones. Vemos que tcpdump parece no tener ningún retraso, mientras que la aplicación puede mostrar 20 milisegundos.

Estamos bastante seguros de que esto no es GC, porque el registro del GC no muestra prácticamente GC completo, y en JDK 6 (por lo que entiendo) el GC predeterminado es paralelo, por lo que no debería detenerse haciendo Full GC).

Parece casi como si hay algún retraso para Selector.select(0) método de Java para devolver la disposición a leer, porque en la capa TCP, que los datos ya está disponible para ser leído (y tcpdump lo está leyendo).

Información adicional: en la carga máxima estamos procesando aproximadamente 6,000 x 150 bytes de media por mensaje, o aproximadamente 900 MB por segundo.

Answer 1

eden colección todavía incurre en una pausa STW por lo que 20ms puede ser perfectamente normal en función del comportamiento de asignación & tamaño/tamaño del conjunto en vivo.

Answer 2

¿Su código Java se está ejecutando bajo RTLinux, o alguna otra distribución con capacidad de programación en tiempo real? Si no, 10-20 mseg de jitter en los tiempos de procesamiento parece completamente razonable y esperado.

Answer 3

Desde el tcpdump faq:

cuando es troquelada vez que un paquete? CÓMO PRECISAR SON LAS HORAS DE TIEMPO?

En la mayoría de los sistemas operativos en los que tcpdump y carrera libpcap, el paquete es el tiempo sellada como parte del proceso de controlador de dispositivo de la interfaz de red o la pila de red, el manejo de la misma. Esto significa que el paquete no tiene el tiempo sellado en el instante en que llega al en la interfaz de red; después del paquete llega a la interfaz de red , habrá un retraso hasta se entrega una interrupción o la interfaz red se sondea (es decir, la interfaz red podría no interrumpe el anfitrión inmediatamente - el conductor puede ajustarse hasta sondear la interfaz si tráfico de la red es pesado, para reducir el número de interrupciones y procesar paquetes más por interrupción), y hay habrá un retraso adicional entre el punto de en el que comienza la interrupción siendo procesado y el la marca de tiempo es generada.

Así que las probabilidades son, la marca de tiempo se realiza en la capa del núcleo privilegiado, y los 20 ms perdidos es el contexto de conmutación de cabeza de nuevo a espacio de usuario y en Java y la lógica de selección de red JVM. Sin más análisis del sistema como un todo, no creo que sea posible hacer una selección afirmativa de la causa.

Answer 4

Tuve el mismo problema en un servicio de Java en el que trabajo. Al enviar la misma solicitud repetidamente desde el cliente, el servidor bloquearía en el mismo lugar en la corriente durante 25-35 ms. Apagar el algoritmo de Nagle en el socket solucionó esto por mí. Esto se puede lograr llamando a setTcpNoDelay (verdadero) en el Socket. Esto puede provocar una mayor congestión de la red porque los ACK se enviarán ahora como paquetes por separado. Ver http://en.wikipedia.org/wiki/Nagle%27s_algorithm para obtener más información sobre el algoritmo de Nagle.