Teniendo en cuenta estos dos comandosvelocidad de -Xms y -Xmx opciones de Java
A:
$ java -Xms10G -Xmx10G myjavacode input.txt
B:
$ java -Xms5G -Xmx5G myjavacode input.txt
Tengo dos preguntas:
-Xmx y -Xms al proceso de ejecución y a la salida de mi programa?Depende del GC que esté utilizando su Java. Los GC paralelos pueden funcionar mejor en configuraciones de memoria más grandes, aunque no soy un experto en eso.
En general, si tiene una memoria más grande, es menos frecuente que tenga que ser GC-ed: hay mucho espacio para la basura. Sin embargo, cuando se trata de un GC, el GC tiene que trabajar en más memoria, que a su vez puede ser más lenta.
@ kd304: Entonces, si mi CPU tiene una RAM grande (digamos 10GB), y supongamos que eso es suficiente para que se ejecute mi aplicación. ¿Te refieres a menos memoria como en Xm/Xms param que usamos más rápido se ejecutará mi código? – neversaint
@ kd304: por cierto, ¿cómo puedo verificar el GC de mi Java que estoy usando? – neversaint
Las CPU no tienen ram. – jjnguy
Es difícil decir cómo la asignación de memoria afectará su velocidad. Depende del algoritmo de recolección de basura que utiliza la JVM. Por ejemplo, si su recolector de basura necesita hacer una pausa para hacer una colección completa, entonces si tiene 10 más memoria de la que realmente necesita, el recolector tendrá 10 basura más para limpiar.
Si está utilizando java 6, puede usar la consola j (en el directorio bin de la jdk) para adjuntarla a su proceso y ver cómo se comporta el recopilador. En general, los coleccionistas son muy inteligentes y no necesitarás hacer ningún ajuste, pero si tienes una necesidad, hay numerosas opciones que tienes para afinar aún más el proceso de recopilación.
El argumento -Xmx define el tamaño máximo de memoria que el montón puede alcanzar para la JVM. Debe conocer bien su programa y ver cómo funciona bajo carga y establecer este parámetro en consecuencia. Un valor bajo puede causar OutOfMemoryExceptions o un rendimiento muy bajo si la memoria del montón de su programa está alcanzando el tamaño máximo de almacenamiento dinámico. Si su programa se ejecuta en un servidor dedicado, puede establecer este parámetro más alto porque no afectará a otros programas.
El argumento -Xms establece el tamaño de la memoria del montón inicial para la JVM. Esto significa que cuando inicie su programa, la JVM asignará esta cantidad de memoria al instante. Esto es útil si su programa consumirá una gran cantidad de memoria de almacenamiento desde el principio. Esto evita que la JVM aumente constantemente el montón y puede obtener algún rendimiento allí. Si no sabe si este parámetro lo ayudará, no lo use.
En resumen, este es un compromiso que debe decidir basado solo en el comportamiento de memoria de su programa.
dijiste 'Si tu programa se ejecuta en un servidor dedicado, puedes establecer este parámetro más alto porque no afectará a otros programas' Creo que si tenemos múltiples procesos ejecutándose en el mismo nodo y si todos tienen sus parámetros XMx configurados, ningún proceso va a otro proceso como con Xmx, la memoria ya ha sido reservada para cada proceso (que no puede ser utilizado por ningún otro proceso) ¿Correcto? – emilly
¿Puede dar su opinión sobre http://stackoverflow.com/questions/39652282/impact-of-heap-parameters-on-gc-performance y http://stackoverflow.com/questions/39652282/impact-of-heap -parameters-on-gc-performance? Gracias de antemano – emilly
He encontrado que, en algunos casos, demasiada memoria puede ralentizar el programa.
Por ejemplo, tenía un motor de transformación basado en hibernación que comenzó a funcionar lentamente a medida que aumentaba la carga. Resultó que cada vez que recibimos un objeto del archivo db, hibernate revisaba la memoria en busca de objetos que nunca volverían a usarse.
La solución fue desalojar los objetos viejos de la sesión.
Stuart
> C:\java -X
-Xmixed mixed mode execution (default)
-Xint interpreted mode execution only
-Xbootclasspath:<directories and zip/jar files separated by ;>
set search path for bootstrap classes and resources
-Xbootclasspath/a:<directories and zip/jar files separated by ;>
append to end of bootstrap class path
-Xbootclasspath/p:<directories and zip/jar files separated by ;>
prepend in front of bootstrap class path
-Xnoclassgc disable class garbage collection
-Xincgc enable incremental garbage collection
-Xloggc:<file> log GC status to a file with time stamps
-Xbatch disable background compilation
-Xms<size> set initial Java heap size
-Xmx<size> set maximum Java heap size
-Xss<size> set java thread stack size
-Xprof output cpu profiling data
-Xfuture enable strictest checks, anticipating future default
-Xrs reduce use of OS signals by Java/VM (see documentation)
-Xcheck:jni perform additional checks for JNI functions
-Xshare:off do not attempt to use shared class data
-Xshare:auto use shared class data if possible (default)
-Xshare:on require using shared class data, otherwise fail.
Los -X opciones no son estándar y están sujetas a cambios sin previo aviso.
(copiar y pegar)
No responde la pregunta. – neo7
¿Su pregunta se refieren a algún problema en el mundo real o es sólo una cuestión teórica? Porque si tiene esa cantidad de RAM en un sistema de 64 bits, puede considerar cambiar sus algoritmos para aprovecharlo, p. Ej. leer/mapear toda la gran entrada.txt en la memoria y realizar operaciones sobre eso. – akarnokd
La respuesta a este tipo de preguntas siempre es "Hacer un punto de referencia y averiguar". –
Le pregunté al mantenedor del paquete JVM y dijo: "En Linux, no estoy seguro de que Xms lo haga a menos que tenga una configuración extraña. Tal vez lo asigne sin MAP_NORESERVE solo para asegurarse de que la RAM realmente está allí. Pero dudo eso." –