2012-04-06 22 views
10

Tengo una aplicación que se encarga de archivar aplicaciones antiguas, lo que hará una gran cantidad de aplicaciones a la vez, por lo que tendrá que ejecutarse durante días.Cuánto tiempo se debe dedicar a la recolección de basura

Cuando mi empresa desarrolló esto, hicieron una buena cantidad de pruebas de rendimiento y parecían sacar números decentes de esto, pero he estado ejecutando un archivo para un cliente recientemente y parece estar funcionando muy lentamente y el rendimiento parece degradarse aún más tiempo si se ejecuta.

No parece haber una pérdida de memoria, ya que desde que lo he monitorizado con jconsole todavía hay mucha memoria disponible y no parece reducirse.

Sin embargo, he notado que el espacio del sobreviviente y el gen titular del montón pueden llenarse rápidamente hasta que aparece una recolección de basura y se soluciona, lo que parece estar sucediendo con bastante frecuencia, lo que no estoy seguro de que pueda ser fuente de la aparente desaceleración.

La aplicación ha estado funcionando ahora durante 7 días 3 horas y de acuerdo con jconsole que ha gastado 6 horas la realización de recogida de basura copia (772, 611 colecciones) y 12 horas y 25 minutos a de compactación marksweep (145,940 colecciones).

Esto parece una gran cantidad de tiempo para gastar en la recolección de basura y me pregunto si alguien ha investigado algo como esto antes y sabe si esto es normal o no.

ediciones

procesamiento local parece ser lento, por ejemplo, estoy mirando a una parte de los registros que se tarda 5 segundos para extraer parte XML de un sobre SOAP utilizando XPath que se anexa a continuación a una cadena buffer junto con una etiqueta raíz ... eso es todo lo que hace. Aún no lo he perfilado, ya que se está ejecutando en producción, tendría que extraer los datos a través de la red o configurar una gran base de prueba en nuestro entorno de desarrollo que puede terminar teniendo que hacer.

Ejecución Java HotSpot VM cliente versión 10.0-b23

En realidad sólo necesitan un alto rendimiento, no se han configurado los parámetros específicos de recolección de basura, estaría funcionando lo que cada vez los valores por defecto serían. ¿No estoy seguro de cómo encontrar qué coleccionistas estarían en uso?

Fix

terminar recibiendo un perfilador de ir en él, resultó la causa de la desaceleración era un código que estaba constantemente recortando las líneas de un cuadro de estado de la salida de las declaraciones de registro que fue bastante mal hechas. Debería haberse dado cuenta de que la recolección de basura fue un síntoma al copiar constantemente el texto de estado en la memoria, en lugar de una causa real.

Cheers Guys.

+0

¿Qué ordenó el juez? – ZenMaster

+0

* (no es una respuesta a su pregunta, de ahí el comentario) * ... * "que hará una gran cantidad de aplicaciones a la vez y, por lo tanto, deberá ejecutarse durante días a la vez". * ... [sic ] ¿Quiere decir que su aplicación no se puede apagar y reiniciar sin necesidad de comenzar todo desde cero? – TacticalCoder

+0

Bueno, si lo detiene, guarda una lista de lo que queda junto con las aplicaciones que no ha podido archivar y que pueden cargarse y volver a ejecutarse. Ese es nuestro plan si no podemos acelerar esto en los próximos días, para desglosar nuestras banderas de archivo en lotes más pequeños. – Dan675

Respuesta

4

De acuerdo con sus números, el tiempo total de recolección de basura fue de aproximadamente 18 horas de un tiempo de ejecución de 7 días. Aproximadamente el 10% del tiempo total de ejecución, eso es levemente elevado, pero incluso si lograste bajar esto al 0%, solo habrías ahorrado un 10% de tiempo de ejecución ... así que si estás buscando ahorros sustanciales, debería ver mejor el otro 90%, por ejemplo con un generador de perfiles.

2

Sin un perfil adecuado, este es un juego de adivinanzas. Como un anectode, sin embargo, hace unos años una aplicación web con la que estaba involucrado en ese momento se desaceleró repentinamente (tiempo de respuesta) por un factor de 10 después de una actualización de JDK.Terminamos persiguiendo a una invocación explícita de GC agregada por un genio que ya no estaba con la compañía.

2

Hay un equilibrio que tratará de mantener entre las huellas del montón JVM y la hora del GC. Otra pregunta podría ser ¿tiene montones (y generaciones) (infra) asignados de tal manera que exige GC demasiado frecuente? Al desplegar JVM muti-tenant en este sistema, he tratado de mantener el equilibrio por debajo del 5% del tiempo total del GC junto con la reducción agresiva del montón para mantener la huella baja (de nuevo, multi-inquilino). El montón y las generaciones SIEMPRE se llenarán SIEMPRE para evitar un GC frecuente a lo que se configure. Elimine el parámetro -Xms para ver un estado estable más realista (si tiene algún tiempo de inactividad)

+1 a la sugerencia de creación de perfiles; puede ser algo que no está relacionado con GC, sino código.

Cuestiones relacionadas