Duración del tiempo GC excesivo en "java.lang.OutOfMemoryError: el límite superior del GC excedió"

Question

Ocasionalmente, en algún lugar entre una vez cada 2 días a una vez cada 2 semanas, mi aplicación se bloquea en un lugar aparentemente aleatorio en el código con: java.lang.OutOfMemoryError: GC overhead limit exceeded. Si I Google este error llego a this SO question y que me llevan a this piece of sun documentation cuales expains:

The parallel collector will throw an OutOfMemoryError if too much time is being spent in garbage collection: if more than 98% of the total time is spent in garbage collection and less than 2% of the heap is recovered, an OutOfMemoryError will be thrown. This feature is designed to prevent applications from running for an extended period of time while making little or no progress because the heap is too small. If necessary, this feature can be disabled by adding the option -XX:-UseGCOverheadLimit to the command line.

Lo que me que mi solicitud está aparentemente gastando el 98% del tiempo total en la recolección de basura dice para recuperar sólo el 2% de la montón.

¿Pero 98% de qué tiempo? ¿El 98% de las dos semanas completas que la aplicación ha estado funcionando? 98% del último milisegundo?

Estoy tratando de determinar el mejor enfoque para resolver realmente este problema en lugar de solo usar -XX:-UseGCOverheadLimit, pero siento la necesidad de comprender mejor el problema que estoy resolviendo.

Answer 1

I'm trying to determine a best approach to actually solving this issue rather than just using -XX:-UseGCOverheadLimit but I feel a need to better understand the issue I'm solving.

Bueno, está usando demasiada memoria, y por lo que parece, es probable que se deba a una pérdida lenta de memoria.

Puede intentar aumentar el tamaño del montón con -Xmx, lo que ayudaría si esto no es una pérdida de memoria sino una señal de que su aplicación realmente necesita mucho almacenamiento y la configuración que tiene actualmente es de muy baja a muy baja. Si se trata de una pérdida de memoria, esto solo pospondrá lo inevitable.

Para investigar si se trata de una pérdida de memoria, solicite a la máquina virtual que descargue Heap en OOM utilizando el conmutador -XX:+HeapDumpOnOutOfMemoryError, y luego analice el volcado de pila para ver si hay más objetos de los que deberían. http://blogs.oracle.com/alanb/entry/heap_dumps_are_back_with es un muy buen lugar para comenzar.

---

Editar: El destino quiso que me pasó a encontrarse con este problema por mí mismo tan sólo un día después de que se hizo esta pregunta, en una aplicación de estilo por lotes. Esto no fue causado por una pérdida de memoria, y tampoco ayudó el aumento del tamaño del almacenamiento dinámico. Lo que hice fue en realidad Disminuir tamaño de pila (de 1GB a 256MB) para hacer GC completos más rápido (aunque algo más frecuente). YMMV, pero vale la pena intentarlo.

Edición 2: No todos los problemas resueltos por el montón más pequeño ... siguiente paso estaba permitiendo el G1 garbage collector que parece que hacer un mejor trabajo que la CMS.

Answer 2

El> 98% se medirá durante el mismo período en el que se recupera menos del 2% de la memoria.

Es muy posible que no haya un período fijo para esto. Por ejemplo, si el cheque de OOM se realizaría después de cada 1,000,000 de verificaciones en vivo de objetos. El tiempo que toma sería dependiente de la máquina.

Lo más probable es que no pueda "resolver" su problema agregando -XX:-UseGCOverheadLimit. El resultado más probable es que la aplicación se ralentice, use un poco más de memoria y luego llegue al punto donde el GC simplemente no recupera ninguna memoria. En cambio, arregle las pérdidas de memoria y luego (si todavía es necesario) aumente el tamaño de su pila.

Answer 3

But 98% of what time? 98% of the entire two weeks the application has been running? 98% of the last millisecond?

La respuesta simple es que no está especificado. Sin embargo, en la práctica, la heurística "funciona", por lo que no puede ser ninguna de las dos interpretaciones extremas que usted postuló.

Si realmente quería saber cuál es el intervalo en el que se realizan las mediciones, siempre podría leer el código fuente OpenJDK 6 o 7. Pero no me molestaría porque no te ayudaría a resolver tu problema.

El "mejor" enfoque es leer un poco sobre la sintonización (comenzando con las páginas de Oracle/Sun), y luego cuidadosamente "girar las perillas de sintonización". No es muy científico, pero el espacio del problema (con precisión prediciendo aplicación + rendimiento del GC) es "demasiado difícil", dadas las herramientas que están actualmente disponibles.