Rendimiento de Java con grandes cantidades de RAM

Question

Estoy explorando la posibilidad de ejecutar una aplicación Java en una máquina con grandes cantidades de RAM (entre 300GB y 15TB, probablemente en una SGI Altix 4700), e I ' Tengo curiosidad sobre cómo es probable que el GC de Java funcione en este escenario.

He oído que las JVM de IBM o JRockit pueden ser más adecuadas para esto que las de Sun. ¿Alguien sabe de alguna investigación o datos sobre el rendimiento de JVM en esta situación?

Answer 1

en la JVM de Sun, puede utilizar la opción -XX: UseConcMarkSweepGC para encender la marca concurrente y barrer colector, lo que evitará casi por completo las fases de "detener el mundo" del algoritmo GC por defecto, a costa de un poco más de sobrecarga.

El consejo de usar más que en VM en una máquina de este tipo está IMHO obsoleto. En las aplicaciones del mundo real, a menudo tiene suficientes datos compartidos para que el rendimiento con el CMS y una JVM sea mejor.

Answer 2

Seguramente la respuesta sobre cómo va a funcionar el GC es "¿a quién le importa?" ;-)

Answer 3

La pregunta es: ¿desea ejecutar en un solo proceso (JVM) o no? Si lo haces, entonces vas a tener un problema. Consulte Tuning Java Virtual Machines, Oracle Coherence User Guide y documentación similar. La regla de oro por la que he operado es intentar evitar montones de más de 1GB. Mientras que un GC completo de 512 MB a 1 GB puede tardar menos de un segundo. Un GC completo de 2-4GB podría tardar 5 segundos o más. Obvio, esto depende de muchos factores, pero la moraleja de la historia es que la sobrecarga del GC no se escala linealmente y una vez que ingresas en el rango de un segundo, el rendimiento se degrada rápidamente.

Answer 4

Esto no responde en absoluto a su pregunta, pero si planea implementar una gran aplicación Java, puede interesarle consultar Azul Systems appliances. Dicen que se puede recolectar basura sin crear una pausa en la aplicación hasta un único montón de 670 GB.

Answer 5

JVM de Sun le permite configurar y optimizar los diablos de la recolección de basura, pero es una ciencia en sí misma: http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html

Es posible que tenga que hacer un poco de lectura e investigación, pero para ese tipo de máquina, GC las configuraciones optimizadas para la máquina y la aplicación probablemente marquen una gran diferencia.

Answer 6

Desde 5.0, el Hotspot JVM utiliza un concepto conocido como Ergonomía para tratar de optimizar el uso de la memoria. Esto se basa en algo más que la gran cantidad de memoria disponible y los efectos de los tamaños de pila, los tamaños de generación y los algoritmos de recolección de basura.

empezar por tener una lectura de este, lo que explica la ergonomía y más:

http://java.sun.com/j2se/reference/whitepapers/memorymanagement_whitepaper.pdf

También hay un tipo llamado Brian Goetz que está escrito numerosos artículos sobre cómo asigna y utiliza la memoria de Java, todos los cuales y más se puede encontrar aquí:

http://www.briangoetz.com/pubs.html

Answer 7

Hay algunas respuestas adicionales en las respuestas anteriores a un similar question

Answer 8

Las únicas personas que realmente se puede decir que está SGI. Las supercomputadoras no se comportan como servidores normales, solo que más grandes.

Sin embargo, he encontrado que Java funciona mejor cuando la memoria es local para los procesadores que acceden a ella. Nota: el GC necesita poder recorrer toda la memoria de un extremo a otro. Esto significa que no se escala bien si tiene un diseño que es como muchas computadoras pegadas entre sí, que puede ser el caso aquí. El tamaño del módulo de memoria es de 32 GB, por lo que puede obtener un mejor rendimiento si limita su JVM para que se ajuste cómodamente a este tamaño.

Answer 9

Es posible que desee considerar ejecutar un clúster virtual Terracotta en esta máquina.

Answer 10

La respuesta aceptada para esta publicación es bastante antigua y ahora está desactualizada. A partir de septiembre de 2014, si está utilizando Java 7, probablemente debería cambiar al recopilador GC1. A partir de los Java 7 Update 4 notas de la versión:.

http://www.oracle.com/technetwork/java/javase/7u4-relnotes-1575007.html

"El colector G1 está destinada a aplicaciones que aprovechan al máximo la gran cantidad de memoria disponible en los servidores con varios de hoy en día, si bien mantienen las latencias de recolección de basura bajo control Aplicaciones que requieren un montón grande, tienen un gran conjunto de datos activos, tienen cargas de trabajo inestables o no, o sufren de largas latencias inducidas por Garbage Collection deberían beneficiarse al cambiar a G1 ".