El uso máximo de la memoria no va más allá de un límite

Veo que con -Xmx2g, la memoria pico alcanza 1G y realiza las principales colecciones (selector de marcas). Con -Xmx3g, alcanza 1.5G y hace una colección importante. Con -Xmg4g, alcanza 2G y realiza colecciones importantes. Pero, desde aquí traté de aumentar la memoria máxima a 6G, 8G, 12G y todas las veces que la memoria pico alcanza 2G realiza colecciones importantes.El uso máximo de la memoria no va más allá de un límite

¿Cómo hacer que funcione más allá de 2G? No encontré ningún ajuste para esto. ¿Los -Xms importan aquí? Para esos -Xmx, hice -Xms la mitad de -Xmx.

Estoy usando Jetty, Java 1.6.024.

ACTUALIZACIÓN: Sí, estoy usando JVM de 64 bits. Las opciones de JVM que estoy usando son: -Xmx6g -Xms3g -XX: MaxPermSize = 256m La forma en que estoy determinando la memoria pico es mirando el gráfico de memoria en JConsole. Alcanza 2G y cae (colección principal). La generación anterior alcanza un máximo de 1.5G y luego ocurre una caída.

Gracias, Cochecitos.

Fuente

2012-04-09 prams

¿Es razonable suponer que está utilizando una JVM de 64 bits? Vale la pena preguntar, porque la JVM de 32 bits tiene un límite de tamaño de 2 GB. – duffymo

Creo que es seguro decir que es una JVM de 64 bits, porque Java terminará sin ejecutar el programa en absoluto si especifica un tamaño de pila mucho más grande de 1500m (el límite exacto depende de JVM). – rob

¿Trataste de jugar con las propiedades -XX? –

Tiene tres regiones de memoria, eden, superviviente y espacio fijo.

Lo que sospecho es que los sucesos es que los espacios permanentes o de edificación no aumentan a medida que aumenta el tamaño máximo.

La razón por la cual estas dos regiones importan es que cuando se llena el espacio fijo se activa un GC completo (sospecho que este tamaño aumenta) Cuando el espacio de eden se llena y no hay suficiente espacio en el espacio de supervivientes para copiar todos los objetos a la izquierda, también se activa un GC completo.

Si esta es la causa de su problema, está creando una gran cantidad de objetos de vida media que es probable que sea un problema de rendimiento, a menos que pueda reducir el número creado. Una alternativa es especificar un nuevo tamaño más grande que aumente el tamaño del edredón.

Trate -mx12g -XX:NewSize=10g - verbosegc

La última opción dará a sus los tamaños de los espacios individuales cuando se limpian.

Fuente

2012-04-10 08:25:45

Peter, gracias por la respuesta. Tengo una pregunta de seguimiento. Uno de los objetos retenidos de nuestro objeto es de aproximadamente 4 MB. Y creamos un objeto por minuto y lo reemplazamos por un objeto de un minuto anterior en un ConcurrentHashMap estático. Hasta donde puedo ver, este es el objeto más grande.Por supuesto, hay muchos otros objetos String y otros objetos temporales, pero todos son mucho más pequeños que 4MB. ¿Es este un tamaño demasiado grande para un espacio Eden de 3G? Porque cuando tuve 6G, probé con NewRatio de 1 y eso no ayudó al uso máximo para ir más allá de 2G. Gracias. – prams

Los objetos grandes se asignan directamente al espacio fijo. Si tiene un objeto que en realidad está hecho de muchos objetos pequeños, entonces deberían asignarse al espacio eden. Para objetos grandes como este, es mejor que los recicles usted mismo si puede de una manera simple. –

Establecer NewSize en tamaño grande ayudó a alcanzar objetos de memoria de pico más altos. Gracias. Le informaré mi configuración y algunos detalles de los objetos que creamos. Y hará una pregunta (en el próximo comentario). El generador de perfiles indica 2 lugares que consumen gran cantidad de memoria: 1) Se crean alrededor de 5 cadenas (cada 110KB) por segundo. 2) Se crea un objeto que contiene 4 objetos (de una sola clase) uno por minuto y se lo reemplaza en un mapa concurrente simultáneo (de modo que el mapa contiene solo 1 objeto en cualquier momento). Cada uno de esos 4 objetos contienen 10K, 10K ArrayLists Fecha y otras cuerdas, etc. – prams

El uso máximo de la memoria no va más allá de un límite

Respuesta

Cuestiones relacionadas