Recolección de basura Java G1 en producción

Lo he estado probando con una aplicación pesada: 60-70GB asignado a heap, con 20-50GB en uso en cualquier momento. Con este tipo de aplicaciones, es un eufemismo decir que su kilometraje puede variar. Estoy ejecutando JDK 1.6_22 en Linux. Las versiones menores son importantes before antes de aproximadamente 1.6_20, había errores en G1 que causaban NullPointerExceptions aleatorios.

He encontrado que es muy bueno para mantenerse dentro del objetivo de pausa que le das la mayor parte del tiempo. El valor predeterminado parece sea una pausa de 100 ms (0.1 segundos), y le he estado diciendo que haga la mitad de eso (-XX:MaxGCPauseMillis=50). Sin embargo, una vez que se queda muy baja en memoria, entra en pánico y hace una recolección de basura completa de stop-the-world. Con 65GB, eso tarda entre 30 segundos y 2 minutos. (El número de CPU probablemente no hace una diferencia; probablemente está limitado por la velocidad del autobús.)

Comparado con CMS (que no es el servidor GC predeterminado, pero debería ser para servidores web y otras aplicaciones en tiempo real), las pausas típicas son mucho más predecibles y se pueden hacer mucho más cortas. Hasta ahora estoy teniendo mejor suerte con CMS para las pausas enormes, pero eso puede ser aleatorio; las estoy viendo solo unas pocas veces cada 24 horas. No estoy seguro de cuál será más apropiado en mi entorno de producción en este momento, pero probablemente G1. Si Oracle sigue afinándolo, sospecho que G1 finalmente será el claro ganador.

Si no tiene un problema con los recolectores de basura existentes, no hay razón para considere G1 en este momento. Si está ejecutando una aplicación de baja latencia, como una aplicación GUI, G1 es probablemente la opción correcta, con MaxGCPauseMillis establecido muy bajo. Si estás ejecutando una aplicación en modo batch, G1 no te compra nada.

Aunque no he probado G1 en producción, pensé que comentaría que los GCs ya son problemáticos para casos sin montones "gigantescos". Específicamente, los servicios con solo, digamos, 2 o 4 conciertos pueden verse gravemente afectados por GC. Los GCS de generación joven no suelen ser problemáticos, ya que terminan en milisegundos de un solo dígito (o como máximo de dos dígitos). Pero las colecciones de la vieja generación son mucho más problemáticas, ya que toman varios segundos con tamaños de la vieja generación de 1 gig o superior.

Ahora: en theory CMS puede ayudar mucho allí, ya que puede ejecutar la mayor parte de su operación simultáneamente. Sin embargo, con el tiempo habrá casos en los que no puede hacer esto y tiene que recurrir a la colección "stop the world". Y cuando eso sucede (después de, digamos, 1 hora not no a menudo , pero aún así demasiado a menudo), bueno, agárrense a sus sombreros de mierda. Puede tardar un minuto o más. Esto es especialmente problemático para los servicios que intentan limitar la latencia máxima; en lugar de tomar, digamos, 25 milisegundos para servir una solicitud, ahora toma diez segundos o más. Para agregar daño al insulto, los clientes a menudo demorarán la solicitud y volverán a intentarlo, lo que llevará a más problemas (también conocido como "tormenta de mierda").

Esta es una área en la que se esperaba que el G1 ayudara mucho. Trabajé para una gran empresa que ofrece servicios en la nube para el almacenamiento y el envío de mensajes; y no pudimos usar CMS ya que, aunque gran parte del tiempo funcionó mejor que las variedades paralelas, tuvo estos colapsos. Así que durante aproximadamente una hora las cosas estuvieron bien; y luego las cosas golpearon el ventilador... y debido a que el servicio se basaba en clústeres, cuando un nodo se metía en problemas, otros solían seguirlo (ya que los tiempos de espera inducidos por GC llevaban a otros nodos a creer que el nodo se había estrellado, lo que llevaba a redireccionamientos).

No creo que GC sea un gran problema para las aplicaciones, y tal vez incluso los servicios no agrupados se vean menos afectados. Pero más y más sistemas están agrupados (esp. gracias a los almacenes de datos NoSQL) y los tamaños de pila están creciendo. OldGen GCs están super-linealmente relacionados con el tamaño del montón (lo que significa que la duplicación el tamaño del montón más que duplica el tiempo de GC, suponiendo que el tamaño del conjunto de datos en vivo también se duplica).

El CTO de Azul, Gil Tene, tiene una buena visión general de los problemas asociados con la Recolección de Basura y una revisión de varias soluciones en su presentación Understanding Java Garbage Collection and What You Can Do about It, y hay detalles adicionales en este artículo: http://www.infoq.com/articles/azul_gc_in_detail .

El Recolector de basura C4 de Azul en nuestra JVM Zing es paralelo y concurrente, y utiliza el mismo mecanismo GC tanto para las generaciones nuevas como para las antiguas, trabajo simultáneo y compactación en ambos casos. Lo más importante es que C4 no tiene un retroceso de stop-the-world. Toda la compactación se realiza simultáneamente con la aplicación en ejecución. Tenemos clientes corriendo muy grandes (cientos de GBytes) con peores tiempos de pausa GC de

El problema con CMS y G1 es que en algún momento la memoria de montón de Java debe ser compactada, y ambos de esos recolectores de basura stop-the-world / STW (es decir, pausar la aplicación) para realizar la compactación. Por lo tanto, mientras que CMS y G1 pueden eliminar las pausas STW, no las eliminan. El C4 de Azul, sin embargo, elimina completamente las pausas STW y es por eso que Zing tiene pausas GC tan bajas incluso para tamaños de montón gigantescos.

Y para corregir una declaración hecha en una respuesta anterior, Zing no requiere ningún cambio en el Sistema Operativo. Se ejecuta como cualquier otra JVM en distribuciones Linux no modificadas.

Ya estamos usando G1GC, desde hace casi dos años. Está funcionando muy bien en nuestro sistema de procesamiento de transacciones de misión crítica, y demostró ser un gran soporte w.r.t alto rendimiento, pausas bajas, concurrencia y gestión de memoria pesada optimizada.

Estamos utilizando los siguientes ajustes de JVM:

-server -Xms512m -Xmx3076m -XX:NewRatio=50 -XX:+HeapDumpOnOutOfMemoryError -XX:+UseG1GC -XX:+AggressiveOpts -XX:+UnlockExperimentalVMOptions -XX:MaxGCPauseMillis=400 -XX:GCPauseIntervalMillis=8000 -XX:+PrintGCTimeStamps -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCApplicationConcurrentTime

Actualizado

-d64 -server -Xss4m -Xms1024m -Xmx4096m -XX:NewRatio=50 -XX:+UseG1GC -XX:+UnlockExperimentalVMOptions -XX:+HeapDumpOnOutOfMemoryError -XX:-DisableExplicitGC -XX:+AggressiveOpts -Xnoclassgc -XX:+UseNUMA -XX:+UseFastAccessorMethods -XX:ReservedCodeCacheSize=48m -XX:+UseStringCache -XX:+UseStringDeduplication -XX:MaxGCPauseMillis=400 -XX:GCPauseIntervalMillis=8000

El colector G1 reduce el impacto de las colecciones completas. Si tiene una aplicación en la que ya ha reducido la necesidad de colecciones completas, el recopilador de barrido de mapas simultáneo es igual de bueno y, en mi experiencia, tiene tiempos de recopilación menores más cortos.

Parece que el inicio de G1 JDK7u4 finalmente está soportado oficialmente, vea el RN para JDK7u4 http://www.oracle.com/technetwork/java/javase/7u4-relnotes-1575007.html .

De nuestras pruebas todavía para grandes JVMs sintonizado CMS todavía actúa mejor que G1, pero supongo que crecerá mejor.

CMS puede conducir a un rendimiento degradado lentamente incluso si lo está ejecutando sin acumular objetos con titularidad. Esto se debe a la fragmentación de la memoria que G1 supuestamente evita.

El mito sobre G1 disponible solo con soporte pagado es solo eso, un mito. Sun y ahora Oracle han aclarado esto en la página de JDK.

Se supone que G1 GC funciona mejor. Pero si el ajuste-XX: Maxgcpausemill es demasiado agresivo, la basura se acumulará demasiado lentamente. Y es por eso que el GC completo se activó en el ejemplo de David Leppik.

Acabo de implementar G1 Garbage Collector en nuestro proyecto Terracotta Big Memory. Al trabajar en diferentes tipos de colectores, G1 nos dio los mejores resultados con menos de 600 ms de tiempo de respuesta.

Puede encontrar los resultados de la prueba (26 en total) aquí

Espero que ayude.

Recientemente me han movido de

CMS a G1GC con 4G heap y procesador de 8 núcleos en servidores con JDK 1.7.45 .

(JDK 1.8.x G1GC se prefiere sobre 1.7 pero debido a algunas limitaciones, tengo que atenerme a la versión 1.7.45)

He configurado debajo de los parámetros clave y he mantenido todos los demás parámetros a valores predeterminados.

-XX:G1HeapRegionSize=n, XX:MaxGCPauseMillis=m, -XX:ParallelGCThreads=n, 
-XX:ConcGCThreads=n apart from -Xms and -Xmx

Si desea ajustar estos parámetros, eche un vistazo a este artículo oracle.

Observaciones Clave:

1. El uso de memoria es consistente con G1GC a diferencia de altos y bajos con CMS
2. El tiempo máximo de pausa GC es menor en comparación con CMS
3. El tiempo dedicado a la recolección de basura es un poco alto en G1GC en comparación con CMS.
4. El número de colecciones importantes es casi insignificante en comparación con CMS
5. El número de colecciones menores está en el extremo superior en comparación con CMS

Pero todavía estoy feliz de que el tiempo máximo de pausa GC sea menor que el de CMS. He establecido el tiempo máximo de pausa GC como 1.5 segundos y este valor aún no se ha cruzado.

Pregunta relacionada:

Java 7 (JDK 7) recolección de basura y documentación sobre G1

Recientemente he migrado parte de Twicsy a un nuevo servidor con 128 GB de RAM y decidí usar la versión 1.7. Comencé usando todos los mismos ajustes de memoria que usé con 1.6 (tengo varias instancias ejecutándose haciendo varias cosas, desde 500mb de montón hasta 15GB, y ahora uno nuevo con 40GB) y eso no funcionó bien en absoluto. 1.7 parece usar más montón que 1.6, y experimenté muchos problemas en los primeros días. Por suerte tenía un montón de RAM para trabajar y me topé con la RAM para la mayoría de mis procesos, pero todavía estaba teniendo algunos problemas. Mi modus operandi normal era usar un tamaño de pila mínimo muy pequeño de 16m, incluso con un montón máximo de varios gigabytes, y luego activar GC incremental. Esto mantuvo las pausas al mínimo. Sin embargo, eso no funciona ahora, y tuve que aumentar el tamaño mínimo a aproximadamente lo que esperaba usar en promedio en el montón, y eso ha funcionado muy bien. Todavía tengo GC incremental activado, pero lo intentaré sin. No hay pausas en absoluto ahora, y las cosas parece que corre muy rápido. Por lo tanto, creo que la moraleja de la historia es que no espere que su configuración de memoria se traduzca perfectamente de 1.6 a 1.7.

G1 hace que la aplicación sea mucho más ágil: la latancia de la aplicación aumentará - la aplicación se puede nombrar como "soft-real-time". Esto se hace mediante la sustitución de dos tipos de carreras de GC (pequeñas menores y una grande en la Generación Titular) a las pequeñas de igual tamaño.

Para más detalles mira esto: http://geekroom.de/java/java-expertise-g1-fur-java-7 /

Estoy trabajando con Java, para montón pequeño y grande, y la cuestión de la GC y GC Completo aparece todos los días, ya que las restricciones pueden ser más estrictas que otras : en cierto entorno, 0.1 segundo de scavenger GC o GC Completo, matar simplemente la fonctionnalité, y tener una configuración y capacidad de grano fino es importante (CMS, iCMS, otros ... el objetivo está aquí para tener el mejor tiempo de respuesta posible con el tratamiento en tiempo casi real (aquí el tratamiento en tiempo real es a menudo 25 ms), por lo que, básicamente, cualquier mejora en GC ergonomy ans heuristique es bienvenida !

Uso G1GC en Java 8 y también con Groovy (también Java 8), y estoy haciendo varios tipos de cargas de trabajo, y overalmente G1GC funciona así:

• El uso de memoria es muy bajo, por ejemplo, 100MB en lugar de 500MB en comparación con la configuración predeterminada de Java

• El tiempo de respuesta es constante y muy bajo

• El rendimiento entre la configuración predeterminada y G1GC es un 20% más lento cuando se usa G1GC en el peor de los casos (sin ajuste, aplicación de subproceso único). Es no mucho teniendo en cuenta el buen tiempo de respuesta y el bajo uso de memoria.

• Cuando se ejecuta desde Tomcat, que es multiproceso, el rendimiento general es un 30% mejor y el uso de memoria es mucho menor, así como los tiempos de respuesta son mucho menores.

Así que, en general, cuando se utilizan cargas de trabajo realmente diversas, G1GC es muy buen colector para Java 8 para aplicaciones multihilo, e incluso para un solo subproceso hay algunos beneficios.

No se sugiere usar java8 w/ G1GC para el cálculo de puntos flotantes con JVM tipo hotspot. Es peligroso para la integridad y precisión de la aplicación.

Https://bugs.openjdk.java.net/browse/JDK-8148175

JDK-8165766

JDK-8186112