Fondo

Contamos con un grupo de aproximadamente 20 linux cuchillas. Algunos se están ejecutando Suse, algunos se están ejecutando Redhat. TODOS comparten NAS espacio que contiene los siguientes 3 carpetas:

  • /NAS/app/java – un enlace simbólico que apunta a una instalación de Java JDK. Actualmente la versión 1.5.0_10
  • /NAS/app/lib – un enlace simbólico que apunta a una versión de nuestra aplicación.
  • /NAS/datos – directorio donde nuestra producción está escrito

Todas nuestras máquinas disponen de 2 procesadores (hyperthreaded) con 4 gb de memoria física y de 4 gb de espacio de intercambio. Limitamos el número de puestos de trabajo de cada máquina puede procesar en un momento dado a 6 (este número es probable que necesita cambiar, pero que no entra en el problema actual, así que por favor ignorar por el momento).

Algunos de nuestros trabajos se establezca un límite máximo de tamaño de pila de 512mb, algunos otros de la reserva de un máximo de tamaño de pila de 2048mb. De nuevo, nos damos cuenta de que podía ir más de nuestra memoria disponible si 6 trabajos iniciados en el mismo equipo con el tamaño de la pila se establece a 2048, pero a nuestro entender esto todavía no ha ocurrido.

El Problema

De vez en cuando un puesto de Trabajo se producirá inmediatamente con el siguiente mensaje:

Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.

Hemos utilizado para atribuye esto a demasiados trabajos que se ejecutan al mismo tiempo en la misma máquina. El problema que sucedió con tan poca frecuencia (tal vez una vez al mes) que se acaba de reiniciar y todo estaría bien.

El problema recientemente se ha metido mucho peor. Todos nuestros trabajos que solicitar un máximo de tamaño de montón de 2048m fallar de inmediato casi todo el tiempo y la necesidad de obtener reiniciado varias veces antes de terminar.

Hemos salido a las máquinas individuales y trató de ejecutar manualmente con el mismo resultado.

Depuración

Resulta que el problema sólo existe para nuestro SuSE cajas. La razón por la que ha estado ocurriendo con más frecuencia es porque hemos estado añadiendo más máquinas, y los nuevos son de SuSE.

‘cat /proc/version’ en el SuSE cuadros nos dan:

Linux version 2.6.5-7.244-bigsmp ([email protected]) (gcc version 3.3.3 (SuSE Linux)) #1 SMP Mon Dec 12 18:32:25 UTC 2005

‘cat /proc/version’ en el RedHat cuadros nos dan:

Linux version 2.4.21-32.0.1.ELsmp ([email protected].build.redhat.com) (gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-52)) #1 SMP Tue May 17 17:52:23 EDT 2005

‘uname-a» nos da los siguientes tipos de máquinas:

UTC 2005 i686 i686 i386 GNU/Linux

No se ejecutan los trabajos en la máquina, y no a otros procesos están utilizando mucho la memoria. Todos los procesos actualmente en ejecución podría a utilizar 100mb total.

‘top’ en la actualidad, se muestra el siguiente:

Mem:   4146528k total,  3536360k used,   610168k free,   132136k buffers
Swap:  4194288k total,        0k used,  4194288k free,  3283908k cached

‘vmstat’ actualmente muestra lo siguiente:

procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
0  0      0 610292 132136 3283908    0    0     0     2   26    15  0  0 100  0

Si arrancamos un trabajo con la siguiente línea de comandos (Max Montón de 1850mb) empieza bien:

java/bin/java -Xmx1850M -cp helloworld.jar HelloWorld
Hello World

Si queremos subir el máximo tamaño de la pila a 1875mb falla:

java/bin/java -Xmx1875M -cp helloworld.jar HelloWorld
Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.

Es bastante claro que la memoria que se está usando actualmente es para el almacenamiento en Búfer y almacenamiento en el Caché y es por eso por lo poco que se muestra como ‘libre’. Lo que no está claro es por qué hay un mágico 1850mb línea donde nada más alto significa que Java no se puede iniciar.

Cualquier explicación sería muy apreciada.

  • Consulte stackoverflow.com/questions/171205/….
  • ¿por qué tienes 32b cuchillas? 😛
  • Hola Randyaa, fue que empezaste a averiguar qué está causando esto? Estoy teniendo el mismo exacto errores cuando intento inicio de un servidor WebLogic… Thx
  • Por desgracia no, hemos implementado algunas técnicas para reducir nuestro uso de la memoria y fueron capaces de conseguir que nuestros max de uso de hasta unos 1gig. Lo siento 🙁
  • +1 Buena cantidad de detalles.
InformationsquelleAutor Randyaa | 2009-06-29

15 Comentarios

  1. 21

    Usted está usando un sistema operativo de 32 bits, por lo que vamos a ver a los límites en el tamaño total, debido a que. Otras respuestas han cubierto de esto con más detalle, así que voy a evitar la repetición de su información.

    Un comportamiento que he notado con nuestros servidores recientemente es que la especificación de un tamaño máximo de pila con -Xmx mientras no se especifica un tamaño mínimo de pila con -Xms llevaría a Java server VM inmediatamente intentar asignar toda la memoria necesaria para el máximo tamaño de la pila. Y claro, si la aplicación se presenta hasta que el tamaño de la pila, que es la cantidad de memoria que necesita. Pero las posibilidades son, sus aplicaciones de comenzar con relativamente pequeños montones y puede requieren el mayor montón en algún momento posterior. Además de especificar el tamaño mínimo de pila le permitirá iniciar su aplicación a empezar con un pequeño montón y crecer poco a poco ese montón.

    Todo esto no va a ayudar a aumentar su tamaño máximo de pila, pero pensé que podría ayudar, así que…

    • Ya he mencionado que no creo que tenga nada que ver con nuestro OS de 32 bits. Ambos SuSE y RedHat máquinas de 32 bits y que no están teniendo el problema. En cuanto a tu sugerencia de establecer un mínimo, he intentado eso y no hacer nada por mí :(.
  2. 15

    Como se sugiere en otras respuestas, el problema se hace por el agotamiento del espacio de direcciones virtuales. Una de 32 bits de linux, espacio de usuario del programa es generalmente limitado a 3 GB de COMO; el resto de 1GB es usado por el kernel (justificación: desde la parte superior de 1GB es de núcleo fijo de asignación no es necesario tocar la tabla de la página al momento de servir syscalls).

    RHEL núcleos, sin embargo, aplicar el llamado de 4 gb/4 GB split, donde el total de 4GB YA está disponible para los procesos del espacio de usuario en el coste de una leve sobrecarga de tiempo de ejecución (el núcleo vive en un aparte de 4GB virtual)

  3. 8

    Ejecutando un sistema operativo de 32 bits es un error; definitivamente, usted debe actualizar a la mayor brevedad posible.

    No sé si Java requiere su montón estar en un único fragmento contiguo, pero si lo hace, pidiendo 1.8 G de montón de 32-bits de la caja suena como una orden de alto. Estás asumiendo que hay un trozo de espacio de direcciones, casi la mitad de ella, libre al inicio de la JVM en tiempo.

    Dependiendo de qué otras bibliotecas se cargan en el tiempo, no puede ser. Las bibliotecas pueden asignar memoria en cualquier lugar que desee, de modo que podría fragmento de su espacio de direcciones lo suficiente como para que 1.8 G no está disponible en un solo fragmento.

    No es sólo acerca de 3G dirección de espacio máximo disponible en Linux de 32 bits de todos modos. Las bibliotecas y la JVM utiliza algunos para empezar.

    • Me gustaría cambiar si pudiera. No me corresponde a mí. Necesito solucionar el problema en la mano, la cual es la razón por la Redhat máquinas nos permiten utilizar 2500+ y ¿por qué el SuSE cuadros nos limitan a 1850.
  4. 4

    Parece que para los servidores de 32 bits hay una JVM limitación de que no puede ser superado (a menos que encuentre un especial JVM de 32 bits que no impone un límite de 2 gb o menos).

    Este hilo en El Lado del Servidor tiene más detalles, incluyendo varias personas que probado varios Jvm en arquitecturas de 32 bits. IBM JVM parece permitir a los más de 100 MB, pero que en realidad no va a obtener lo que desea.

    http://www.theserverside.com/discussions/thread.tss?thread_id=26347

    El «real» de la solución es utilizar un servidor de 64 bits con una JVM de 64 bits para obtener montones de más de 2GB por proceso. Sin embargo, es importante considerar también el impacto de aumentar su tamaño de las direcciones (no sólo en el espacio direccionable) mediante el uso de una JVM de 64 bits. Probablemente habrá memoria y el rendimiento de los impactos para el procesamiento con menos de 4GB de memoria.

    Alimento para el pensamiento: ¿cada uno de estos trabajos realmente requieren 2 gb de memoria? ¿Hay alguna forma para los trabajos a ser modificado para que se ejecute dentro de 1.8 GB por lo que este límite no es un problema?

    • Yo realmente no creo que sea una de 32 bits problema. Ambas máquinas están ejecutando un OS de 32 bits y cada uno de ellos tienen diferentes límites. El RedHat cajas límite es de alrededor de 2500+MB y el SuSE cajas están en algún lugar alrededor de 1850Mb.
    • Como para cambiar los sistemas o «realmente» la necesidad de 2GB… Tenemos la intención de hacer algunos cambios para reducir la huella de memoria, sin Embargo, en este punto sí es realmente necesaria.
  5. 3

    ulimit max tamaño de la memoria virtual y memoria ilimitada?

    • ulimit es ilimitado en ambos. Dónde puedo consultar el límite de memoria virtual?
    • Uso ulimit con el modificador-a. ulimit -a
  6. 3

    Escribí dos aplicaciones, una de tamaño mediano, y el otro, bastante pequeña. Me gustaría fuego
    los de tamaño mediano (en linux, centos), sin ningún tipo de argumentos, (java server), y que
    corriendo bien. Pero cuando luego disparó hasta los más pequeños de la aplicación con «java cliente», se diría
    yo no podía reserva de espacio suficiente, y no funcionaría. He experimentado, y se utiliza el -Xms y -Xmx tanto con 10m, y ambos se ejecute sin queja… Vaya usted a saber!

  7. 2

    Esta manera tal vez fuera de la pista, pero hay dos cosas que saltan a la mente. Ambos de los siguientes se supone que está ejecutando una versión de 32 bits de Linux.

    Hay un proceso de límite de tamaño en linux, parece recordar que en CentOS fue de alrededor de 2.5 gb y se configura en el núcleo (es decir, un recomple a cambio). El proceso podría ser que golpear una vez se suman todas las JVM código + Permgen space y todo el resto de la JVM bibliotecas.

    La segunda cosa es algo que he encontrado que puede ejecutar fuera del espacio de direcciones, suena raro lo sé. Había un problema de Glassfish con un 1.5 Gb montón, cuando se trató de complie un JSP mi bifurcan javac fracasaría porque el sistema operativo no podía asignar suficiente espacio de direcciones para el proceso recién creado a pesar de que hubo 12 gb de memoria en el cuadro. Puede ser que exista algo similar sucede aquí.

    Me temo que la única solución a los dos anteriores, donde la actualización a un núcleo de 64 bits.

    Espero que esto sea de alguna utilidad.

    • Como he mencionado ya, si tanto el SuSE cajas y RedHat cajas tenido este problema, me gustaría estar de acuerdo con usted. Ambos son de 32 bits OS y tienen diferentes límites. Redhat parece estar en algún lugar alrededor de 2500+ MB mientras que el SuSE cuadros parecen estar en algún lugar alrededor de 1850 MB.
    • Las diferentes distribuciones podría tener distintos valores predeterminados para el proceso de los límites de tamaño. Tienen diferentes versiones de kernel, también.
  8. 2

    Tienes que mirar en la actualización de su sistema operativo y Java. Java 5.0 es de EOL, pero si no se puede actualizar a Java 6, se puede utilizar el último nivel de revisión 22!

    De Windows de 32 bits está limitado a ~ 1.3 GB, por lo que están haciendo bien en sí misma la máxima de 1.8. Nota: este es un problema con el continuo de la memoria, y como el sistema ejecuta su espacio de memoria puede obtener fragmentada por lo que no es sorpresa que me tiene este problema.

    Un sistema operativo de 64 bits, no tiene este problema ya que tiene mucho más espacio virtual, usted incluso no tiene que actualizar a una versión de 64 bits de java para tomar ventaja de esto.

    Por CIERTO, en mi experiencia, la de 32 bits de Java 5.0 puede ser más rápido que el de 64 bits de Java 5.0. No fue hasta muchos años después de que Java 6 update 10 fue más rápido de 64 bits.

  9. 2

    He actualizado a la memoria de una máquina de 2 gb a 4 GB, y empezó a ser el error de inmediato:

    $ java -version
    Error occurred during initialization of VM
    Could not reserve enough space for object heap
    Could not create the Java virtual machine.

    El problema era que el ulimit, que se me había fijado en 1 GB para el espacio direccionable.
    El aumento a 2GB resuelto el problema.

    -Xms y -Xmx no tuvo ningún efecto.

    Se parece a java intenta obtener de la memoria en proporción a la memoria disponible, y se produce un error si no se puede.

  10. 2

    Pasos a ejecutar …. para resolver el
    Error durante la inicialización de la VM
    No podía reserva de espacio suficiente para el objeto del montón
    No se pudo crear la máquina virtual de Java.

    Paso 1: Reducir la memoria de lo que antes se usa..
    java -Xms128m -Xmx512m -cp simple.jar

    paso 2: Quitar la RAM algún momento de la placa madre y la conecte y reiniciar
    * puede que se suelte el bloqueo del montón área de memoria..
    java -Xms512m -Xmx1024m -cp simple.jar

    La esperanza de que va a funcionar bien ahora… 🙂

  11. 2

    Recientemente he enfrentado a este problema. Tengo 3 aplicaciones java que empezar con 1024m o 1280m tamaño de la pila.
    Java es mirar el espacio disponible en el espacio de intercambio, y si no hay suficiente memoria disponible, la jvm salidas.

    Para resolver el problema, tuve que terminar varios programas que había una gran cantidad de memoria virtual asignada.

    Estaba corriendo en x86-64 de linux con una jvm de 64 bits.

  12. 1

    ¿Cuál es la JVM utiliza ?
    Sé que BEA JRockit no exceda de 1850mB para max tamaño de la pila. No falla, pero advierte al usuario de que no va a utilizar más de 1850mB.

    No sé por qué hay un límite, pero sé que existe para BEA JRockit.

    Saludos.

    • Sólo estamos utilizando la JVM de Sun. la versión de java «1.5.0_10» Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_10-b03) Java HotSpot(TM) Servidor VM (construir 1.5.0_10-b03, de modo mixto)
    • Acabo de probar con el Sol cliente máquina virtual en Windows XP. Arriba Xmx1640M me sale el mismo error como: Error durante la inicialización de la VM no Pudieron reservar suficiente espacio para un montón de objeto no se Pudo crear la máquina virtual de Java. El programa que he probado es HelloWorld. El límite está fijado por la JVM.
    • Oracle JRockit, a diferencia de la JVM:s de Sun e IBM, puede utilizar un no-contiguos montón. Esto significa que usted puede conseguir casi 3 GB en Windows, no estoy seguro de cuánto puede obtener en Linux, aunque. Ver este blog para más información; blogs.oracle.com/jrockit/2008/09/…
  13. 1

    Dado que ninguna de las otras sugerencias que han trabajado (incluyendo muchas cosas que me hubiera propuesto a mí mismo), para ayudar a solucionar aún, podría usted intentar ejecutar:

    sysctl -a

    Tanto en el SuSE y RedHat máquinas para ver si hay alguna diferencia? Supongo que las configuraciones predeterminadas son diferentes entre estas dos distribuciones que está causando esto.

    • Es /sbin/sysctl en su camino? En realidad, sólo tratar de ejecutar /sbin/sysctl-a.
  14. 1

    Estoy usando SOA env, Disminución de la Xmx de 1024 768 en setSOADomainENV.cmd resuelto el problema.

    REM set DEFAULT_MEM_ARGS=-Xms512m -Xmx1024m
    set DEFAULT_MEM_ARGS=-Xms512m -Xmx768m
    • Bienvenido a ASÍ. Estás seguro de que has respondido a la pregunta correcta?
  15. -3

    En Windows, he resuelto este problema editando directamente el archivo /bin/cassandra.el murciélago, el cambio en el valor de la «Xms» y «Xmx» JVM_OPTS parámetros. Puedes probar a editar el /bin/cassandra archivo. En este archivo veo comentó variable JVM_OPTS, trate de comentar y editar.

Dejar respuesta

Please enter your comment!
Please enter your name here