Configuraciones de memoria Eclipse al obtener "Java Heap Space" y "Out of Memory"
flex (11)
-xms es la memoria de inicio (en el inicio de VM), -xmx es la memoria máxima para la VM
- eclipse.ini: la memoria de la VM que ejecuta el eclipse
- jre setting: la memoria para los programas java se ejecuta desde eclipse
- catalina.sh: la memoria para su servidor tomcat
Al intentar lanzar y ejecutar un proyecto de flex / java en eclipse, seguí obteniendo una "Excepción de memoria insuficiente" y "Java Heap Space" usando Eclipse, Tomcat y un JRE.
Mientras investigaba tratando de ajustar la configuración de memoria encontré tres lugares para ajustar estos:
Eclipse.ini
La configuración de JRE en Ventana> Preferencias
Catalina.sh o Catalina.bat
¿Cuáles son las diferencias entre establecer -xms y -xmx en estos diferentes lugares y lo que hace es decir?
¿Hay alguna manera de verificar que estas configuraciones de memoria se estén configurando en consecuencia?
¿Cuáles son los valores óptimos -xms y -xmx para una computadora con 2 gb de RAM?
¿Alguna otra sugerencia de memoria?
Gracias.
Adobe Flash Builder 4.6 Léame.pdf recomienda que edite el archivo eclipse.ini para su instancia de Eclipse, de modo que incluya las siguientes configuraciones:
-vmargs -Xms256m -Xmx512m -XX:MaxPermSize=256m -XX:PermSize=64m
Antes que nada, sugiero que reduzca el problema a qué componente arroja la "Excepción de falta de memoria".
Esto podría ser:
- Eclipse en sí (lo cual dudo)
- Su aplicación bajo Tomcat
Los parámetros de JVM -xms
y -xmx
representan la "memoria de inicio" del montón y la "memoria máxima". Olvide la "memoria de inicio". Esto no lo ayudará ahora y solo debería cambiar este parámetro si está seguro de que su aplicación consumirá esta cantidad de memoria rápidamente.
En producción, creo que el único parámetro que puede cambiar es el -xmx
bajo los archivos Catalina.sh o Catalina.bat. Pero si está probando su aplicación web directamente desde Eclipse con un entorno de depuración configurado de Tomcat, puede ir a "Configuraciones de depuración"> "Apache Tomcat"> "Argumentos"> "Argumentos VM" y establecer allí el -xmx
.
En cuanto al óptimo -xmx
para 2gb, esto depende mucho de su entorno y del número de solicitudes que su aplicación podría tomar. Intentaría valores desde 500mb hasta 1gb. Compruebe el límite de "zona" de la memoria virtual del sistema operativo y el límite de la propia JVM.
Encontramos 2 problemas en nuestro caso.
La memoria se detenía y era obligatorio establecer el tamaño de la permanente de inicio a un valor más alto. Supongo que estaba usando memoria más rápido y que luego podía asignarla. En nuestro caso. -XX: PermSize = 256m -XX: MaxPermSize = 256m
Estamos utilizando Clearcase y el plugin de Rational Clearcase SCM (7.0.0.2) fue utilizado en Eclipse. El plugin fue el caso de por qué Eclipse se estrelló. Y por el momento no sabemos por qué, pero podría ser bueno saber para otros. Fue forzado a desactivarlo.
Hay un par de ajustes de memoria diferentes por una buena razón.
La configuración de la memoria del eclipse se debe a que Eclipse es un gran programa Java. si vas a tener una gran cantidad de archivos abiertos en un par de proyectos, entonces querrás darle más carnero a Eclipse. Este es un problema solo en los sistemas "empresariales". Normalmente, los proyectos personales no utilizan tantos identificadores o interfaces de archivo.
La configuración de JRE es la cantidad de RAM que permite el tiempo de ejecución de Java cuando ejecuta su proyecto. Este es probablemente el que desea cuando está ejecutando alguna aplicación que acapara la memoria. He llevado a cabo proyectos matemáticos que necesitaban unos pocos gigs de RAM y realmente tenía que decirle al JRE que estaba bien, la JVM seguía asumiendo que mi programa estaba en un estado fugitivo con fugas, pero lo estaba haciendo a propósito, y tenía que decirle a JVM específicamente lo que se le permitió usar.
Entonces la configuración de memoria de Catalina es para el servidor de aplicaciones Tomcat. Ese servidor necesita memoria para cada aplicación y usuarios simultáneos. Esto se combina con el número de JRE porque su proyecto podría ser una aplicación web y no estoy seguro de cuál necesita la memoria.
Mi FLASHBuilder se cuelga todo el tiempo cuando intento lanzar una nueva versión o abuso de las funciones "Marcar apariciones" y "Vincular con el editor".
He mejorado significativamente mi rendimiento de flash siguiendo estos pasos http://www.redcodelabs.com/2012/03/eclipse-speed-up-flashbuilder/
Especialmente configurando FlashBuilder.ini en la siguiente configuración
-vm
C:/jdk1.6.0_25/bin
-startup
plugins/org.eclipse.equinox.launcher_1.2.0.v20110502.jar
–launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_64_1.1.100.v20110502
-product
org.eclipse.epp.package.jee.product
–launcher.defaultAction
openFile
–launcher.XXMaxPermSize
256M
-showsplash
org.eclipse.platform
–launcher.XXMaxPermSize
256m
–launcher.defaultAction
openFile
-vmargs
-server
-Dosgi.requiredJavaVersion=1.5
-Xmn128m
-Xms1024m
-Xmx1024m
-Xss2m
-XX:PermSize=128m
-XX:MaxPermSize=128m
-XX:+UseParallelGC
Mi configuración de hardware es intel i3 cpu, 4gb DDR3, windows 7 64Bit.
Nos enfrentamos a un problema de espacio de pila con Ant al tratar de construir un proyecto Flex muy grande que no se pudo resolver aumentando la memoria asignada a Ant o agregando el fork = param verdadero. Terminó siendo un error en Flex 3.4.0 sdk. Finalmente me di cuenta de esto después de sondear a los desarrolladores para su versión sdk y volver a 3.3.0.
Para los curiosos.
Seguí el error hasta un archivo de interfaz que tenía un par de acceso adicional agregado "get / set maskTrackSkin". El error de espacio de pila se acelera si se agregaron funciones adicionales a la interfaz y, para empeorar las cosas, la interfaz no estaba en el proyecto que obtenía el error de espacio de pila. Espero que esto ayude a alguien.
Si ve una memoria insuficiente, considere si eso es plausible: ¿realmente necesita tanta memoria? Si no (es decir, cuando no tiene objetos grandes y no necesita crear millones de objetos por algún motivo), es probable que tenga una pérdida de memoria.
En Java, esto significa que mantiene una referencia a un objeto en algún lugar, aunque ya no lo necesite. Las causas comunes para esto es olvidarse de llamar a close () en los recursos (archivos, conexiones de base de datos, instrucciones y conjuntos de resultados, etc.).
Si sospecha una fuga de memoria, use un generador de perfiles para encontrar qué objeto ocupa toda la memoria disponible.
También tenemos algunos problemas con la memoria en Eclipse, pero la forma en que es para nosotros, no es cuando la ejecución real, es cuando Eclipse está haciendo una actualización (manual o automática), o si intenta construirlo, eclipse crash y apagar.
En los registros hay algo de información:
Heap
def new generation total 36352K, used 11534K [0x10040000, 0x127b0000, 0x14f00000)
eden space 32320K, 29% used [0x10040000, 0x10994c30, 0x11fd0000)
from space 4032K, 49% used [0x123c0000, 0x125aed80, 0x127b0000)
to space 4032K, 0% used [0x11fd0000, 0x11fd0000, 0x123c0000)
tenured generation total 483968K, used 125994K [0x14f00000, 0x327a0000, 0x50040000)
the space 483968K, 26% used [0x14f00000, 0x1ca0ab38, 0x1ca0ac00, 0x327a0000)
compacting perm gen total 58112K, used 57928K [0x50040000, 0x53900000, 0x60040000)
the space 58112K, 99% used [0x50040000, 0x538d2160, 0x538d2200, 0x53900000)
No shared spaces configured.
Incluso si ajusto el eclipse.ini para usar estos valores, no parece aplicarse.
-showsplash
org.eclipse.platform
--launcher.XXMaxPermSize
1024M
-framework
plugins/org.eclipse.osgi_3.4.2.R34x_v20080826-1230.jar
-vmargs
-Dosgi.requiredJavaVersion=1.5
-XX:MaxPermSize=256m
-Xms512m
-Xmx1024m
Cualquiera que haya visto este problema antes?
Agregaré que el proyecto que se usa es muy grande.
Tengo estas configuraciones:
-vmargs
...
-Duser.name=...
-XX:PermSize=256m
-XX:MaxPermSize=256m
-Xmn128m
-Xms256m
-Xmx768m
Eclipse se colgó aleatoriamente antes de establecer PermSize igual a MaxPermSize.
Tomcat en Eclipse no usa catalina.sh o bat. Para configurar la memoria para Tomcat administrado, use la configuración de VM en la configuración de ejecución del servidor