¿El mejor sistema operativo para implementar una aplicación Java de baja latencia?

Question

Tenemos un sistema de negociación de baja latencia (controladores de alimentación, análisis, entrada de pedidos) escrito en Java. Utiliza TCP y UDP extensamente, no usa Infiniband u otras redes no estándar.

¿Alguien puede comentar las compensaciones de varios sistemas operativos o configuraciones de sistema operativo para implementar este sistema? Si bien el rendimiento es obviamente importante para mantener el ritmo de los precios de los alimentos modernos, la latencia es nuestra prioridad número uno.

Solaris parece ser un candidato natural ya que crearon Java; ¿Debo usar procesadores Sparc o x64?

He oído cosas buenas sobre RHEL y SLERT, son esas las versiones correctas de Linux para usar en nuestra evaluación comparativa.

¿Alguien ha probado Windows con los SO anteriores? ¿O se supone que no se mantiene al día?

Me gustaría dejar el debate Java vs C++ para un hilo diferente.

Answer 1

A los vendedores les encanta este tipo de punto de referencia. Usted tiene el código, ¿verdad?

IBM, Sun/Oracle, HP les encantará ejecutar su aplicación en su equipo para demostrar sus ventajas.

Haz que hagan esto. Si tiene código, haga que los proveedores ejecuten una demostración en su equipo para mostrar cuál es la mejor para sus necesidades.

Es fácil, indoloro, gratis, y factual. La decisión final será fácil y obvia. Y sabrá cómo instalar y sintonizar para maximizar el rendimiento.

---

Lo que me gusta hacer es predecir este tipo de cosas antes de se escribe el código. Demasiados clientes han pedido una recomendación H/W y OS antes de que hayamos terminado de identificar todos los casos de uso. Pedir ese tipo de precognición es simple locura.

Pero tiene código. Puede producir casos de prueba que ejercen su código. Eso es perfecto.

Answer 2

Probablemente me preocupe que la recolección de basura cause latencia mucho antes que el sistema operativo; ¿Has buscado afinar eso en absoluto?

Si estuviera dispuesto a pasar el tiempo probando diferentes sistemas operativos, probaría Solaris 10 y NetBSD, y probablemente una variante de Linux para una buena medida.

Experimentaría con las arquitecturas de 32 contra 64 bits; 64 bit le dará un espacio de direcciones de montón más grande ... pero le llevará más tiempo abordar cada bit de memoria.

Supongo que ha perfilado su aplicación y sabe dónde están los cuellos de botella; por el comentario sobre GC, has hecho eso. En ese caso, su aplicación no debería estar unida a la CPU, y la arquitectura del chip no debería ser una preocupación principal.

Answer 3

Recomiendo encarecidamente que busque un sistema operativo con el que ya tenga experiencia. Solaris es una bestia extraña si solo conoces Linux, p.

También recomiendo usar una plataforma realmente compatible con de Sun, ya que esto hará que sea mucho más fácil obtener asistencia profesional cuando REALMENTE, REALMENTE la necesite.

http://java.sun.com/javase/6/webnotes/install/system-configurations.html

Answer 4

No creo entornos de código administrado y procesamiento en tiempo real van muy bien juntos. Si realmente te preocupa la latencia, elimina la capa impuesta por el código administrado. Este no es un argumento Java vs C++, sino un argumento Java/C#/... vs C/C++/FORTRAN/..., y creo que es una discusión de diseño válida.

Y sí, me refiero a FORTRAN, ejecutamos varios sistemas casi en tiempo real con una base de FORTRAN.

Answer 5

Una forma de administrar la latencia es tener varias JVM dividiendo el trabajo con montones más pequeños para que detener la recolección de basura mundial no consuma demasiado tiempo cuando sucede y afecte menos procesos.

Otro enfoque es cargar un conjunto de JVM con memoria suficiente y asignar los procesos para garantizar que no se detendrá la recolección de basura mundial durante las horas que usted se preocupa por la latencia (si esto no es un 24/7 aplicación) y reinicie las JVM en horas de inactividad.

También debe considerar otras implementaciones de JVM como una posibilidad (como JRocket). Por supuesto, si alguno de ellos es apropiado depende completamente de su aplicación específica.

Si cualquiera de los anteriores es importante para su enfoque, afectará la elección del sistema operativo. Por ejemplo, si va con otra implementación de JVM, eso podría limitar las opciones de SO, y si usa clústeres o ejecuta varias JVM para la aplicación, eso podría requerir algunas mejores herramientas de SO subyacentes para administrar de manera efectiva, influyendo aún más en la elección del sistema operativo .

Answer 6

Para un entorno comercial, además de una baja latencia, probablemente le preocupe la consistencia y la latencia, por lo que concentrarse en reducir al máximo el impacto de las pausas de GC puede proporcionarle más beneficios que las diferentes opciones de SO.

• El G1 garbage collector en las versiones recientes de Soles Hotspot VM mejora detener el mundo se detiene mucho, de una manera similar a la JRockit VM
• Para garantías de rendimiento real, aunque, Azul Systems versión del compilador Hotspot en su Java dispositivo entrega las pausas garantizadas más bajas disponibles, también se amplía a un tamaño masivo: 100 s de pila GB y 100 s de núcleos.
• me descarto de Java en tiempo real - a pesar de que te dan garantías de respuesta, te sacrificas rendimiento para conseguir esas garantías

Sin embargo, si su planificación sobre el uso de su sistema de comercio en un entorno donde cada microsegundo cuenta, realmente vas a tener que vivir con la falta de consistencia que obtendrás de la generación actual de máquinas virtuales, ninguna de ellas (excepto en tiempo real) garantiza pausas GC de microsegundos bajos. Por supuesto, en este nivel se encontrará con los mismos problemas de la actividad del sistema operativo (prevención de procesos, manejo de interrupciones, fallas de página, etc.). En este caso, una de las variantes en tiempo real de Linux lo ayudará.

Answer 7

No excluiría Windows de esto solo porque es Windows. Mi expiriencia en los últimos años ha sido que las versiones de Windows de Sun JVM solían ser las más maduras en cuanto a rendimiento, en comparación con Linux o Soaris x86 en el mismo hardware. La JVM para Solaris SPARC también puede ser buena, pero supongo que con Windows en x86 obtendrá más potencia por menos dinero.

Answer 8

La elección del sistema operativo o configurable es completamente redundante teniendo en cuenta la disponibilidad de telas de red más rápidas.

Mire 10GigE con ToE NICs, o la solución más rápida de 4X QDR (40Gbs) InfiniBand pero con IPoIB presentando una interfaz Ethernet estándar y enrutamiento.