¿Ventajas/inconvenientes de ejecutar JVM de 64 bits en un servidor Linux de 64 bits?

Question

Ejecutamos Sun Java 5 JVM de 32 bits en servidores Linux 2.6 de 64 bits, pero aparentemente esto limita nuestra memoria máxima por proceso a 2 GB. Por lo tanto, se ha propuesto que actualicemos a las JVM de 64 bits para eliminar la restricción. Actualmente ejecutamos varias JVM (instancias de Tomcat) en un servidor para mantenernos por debajo del límite de 2 GB, pero nos gustaría consolidarlas con el fin de simplificar la implementación.

Si ha hecho esto, ¿puede compartir sus experiencias, por favor? ¿Está ejecutando JVM de 64 bits en producción? ¿Recomendaría quedarse en Java 5, o estaría bien moverse a Java 6 y 64 bits simultáneamente? ¿Deberíamos esperar problemas de rendimiento, ya sea mejores o peores? ¿Hay alguna área en particular en la que deberíamos enfocar nuestras pruebas de regresión?

¡Gracias por cualquier consejo!

Answer 1

En el Centro de Operaciones Científicas Kepler tenemos cerca de 50 máquinas con 32-64G cada uno. Los montones de JVM son típicamente 7-20G. Estamos utilizando Java 6. El sistema operativo tiene kernel Linux 2.6.

Cuando emigraron a 64bit que esperaba que habría algunos problemas con el funcionamiento de la JVM de 64 bits, pero realmente no ha habido. Las condiciones de falta de memoria son más difíciles de depurar ya que los volcados de almacenamiento dinámico son mucho más grandes. El Java Service Wrapper necesitaba algunas modificaciones para admitir tamaños de montón más grandes.

hay algunos sitios en la web alegando GC no escala bien más allá de 2G, pero no he visto ningún problema. Finalmente, estamos haciendo una computación intensiva intensiva y bastante interactiva. Nunca he mirado las diferencias de latencia; supongo que es el peor de los casos La latencia de GC será más larga con los tamaños de montón más grandes.

Answer 2

se utiliza una JVM de 64 bits con un montón de alrededor de 40 Gb  . En nuestra aplicación, una gran cantidad de datos se almacena en caché, lo que resulta en una gran generación "antigua". La configuración predeterminada de recolección de basura no funcionaba bien y necesitaba una puesta a punto dolorosa en la producción. Lección: asegúrese de tener una infraestructura de prueba de carga adecuada antes de escalar de esta manera. Dicho esto, una vez que tenemos los problemas, el rendimiento del GC ha sido excelente.

Answer 3

Puedo confirmar la experiencia de Sean. Estamos ejecutando Java puro, servicios web computacionalmente intensivos (integración Jetty casera, con más de 1k subprocesos de servlet, y> 6Gb de datos cargados en la memoria), y todas nuestras aplicaciones se ajustaron muy bien a una JVM de 64 bits cuando migrado hace 2 años. Aconsejaría utilizar la última JVM de Sun, ya que se han realizado mejoras sustanciales en la sobrecarga del GC en los últimos lanzamientos. Tampoco tuve ningún problema con la envoltura de Tanukisoftware.

Answer 4

Cualquier código JNI que haya escrito que asume que se está ejecutando en 32 bits tendrá que ser vuelto a probar. Para problemas que puede ejecutar al portar el código c de 32 a 64 bits, consulte este enlace. No es específico de JNI, pero aún se aplica. http://www.ibm.com/developerworks/library/l-port64.html

Answer 5

Si utiliza numactl --muestra puede ver el tamaño de los bancos de memoria en su servidor. He encontrado que el GC no escala bien cuando usa más de un banco de memoria. Esto es más un hardware que un problema de software en mi humilde opinión, pero puede afectar sus tiempos de GC de todos modos.

Answer 6

Después de migrar a 64bits JDK6 de 32 bits de Windows JDK5 (servidor), llegamos fuga en "perm espacio gen" bloque de memoria. Después de jugar con los parámetros JDK, se resolvió. Espero que seas más afortunado que nosotros.