¿Cuál es el máximo espacio montón de Java para SuSE Linux

Question

Esta pregunta se relaciona con Java no arranca - No se pudo resrve suficiente espacio para el montón de objetos y debería ser bastante fácil de entender. Sin embargo; mis búsquedas no han dado nada útil.

En esencia tenemos 2 32 bits (sistemas operativos RedHat y SuSE) en diferentes máquinas con el mismo hardware. Ambos utilizan la misma JVM tanto la ejecución de la misma línea de comandos. RedHat funciona perfectamente bien, pero SuSE informa de que no hay suficiente memoria.

Sólo necesitamos saber si se trata de una limitación de la versión de SuSE estamos utilizando o si se trata de otra cosa.

'cat / proc / version' nos da:

Linux version 2.6.5-7.244-bigsmp (geeko@buildhost) (gcc version 3.3.3 (SuSE Linux)) #1 SMP Mon Dec 12 18:32:25 UTC 2005

'uname -a' nos da lo siguiente en ambos tipos de máquinas:

UTC 2005 i686 i686 i386 GNU/Linux

Answer 1

El límite de memoria de JVM está relacionado con la mayor libre contigua bloque disponible, no la cantidad de memoria libre. El límite varía desde alrededor de 1,4 GB a un poco más de 2,0 GB, y depende de donde el sistema operativo pone varias cosas en la memoria. No sé los detalles de donde RedHat o SuSE material de carga en la memoria, pero podría ser que suse es el mapeo de alguna biblioteca a una dirección en el medio de memoria RAM, donde Redhat podría asignarla al final (especular).

Y recuerde que su uso de memoria real en Java es más lo que se especifica para -Xmx. Los otros ajustes de la memoria también afectan al tamaño de su pila (como PermGen). Por lo que también podría ser que el espacio permanente en Suse tiene un valor predeterminado larget que en RedHat.

Además, dependiendo del perfil de asignación de memoria de su aplicación, es posible salir con un tamaño de la pila más pequeña y diferentes opciones de recogida de basura. Hay algunos detalles aquí ( http://java.sun.com/performance/ referencia / whitepapers / tuning.html) y otros lugares. Por ejemplo, si asigna una gran cantidad de pequeños bloques temporales, querrá diferentes ajustes de GC que si usted tiene una gran cantidad de bits, objetos de larga vida.

En cuanto a la cuestión vinculada, por qué no usar RedHat? Eso podría ser una solución simplista, pero garantizo que va a arreglar el problema más rápido que ahondar profundamente en el arcano mundo del tuning Java y gestión de memoria SO: P

Answer 2

En primer lugar, usted está loco para estar ejecutando un sistema operativo de 32 bits cuando se tiene tanta presión de espacio de direcciones. Migrar a una JVM de 64 bits en Linux de 64 bits. ¿Cuánto tiempo tiene ya perdido tratando de diagnosticar este problema que debe haber sospechado desde el principio se iría con el mayor espacio de direcciones de un sistema de 64 bits?

En segundo lugar, es bien sabido que de todos los proveedores de Linux Red Hat tiene la mayoría de los ingenieros del kernel en el personal y hace algunos ajustes serios para los granos en sus productos RHEL. Estos a menudo incluyen parches para grandes cargas de trabajo como el suyo (bueno, es una gran carga de trabajo para un sistema de 32 bits, no es nada especial sobre 64 bits). Así que hay alguna posibilidad de que el motivo es que en última instancia RHEL tiene otros clientes que hacen el mismo cosas locas como usted y que está beneficiando del trabajo que hicieron para apoyar a los clientes.

Finalmente, sin embargo, ya que sospecho que va a insistir en tratar de encontrar una manera de hacer esto en SuSE 32 bits voy a señalar que Linux ofrece una variedad de espacio de direcciones compensaciones en x86 de 32 bits, y es posible (pero no seguro) que sus sistemas SuSE sólo tienen un equilibrio diferente seleccionado. Si puede abrir la configuración de los núcleos en ejecución (a menudo en / boot / config ....) entonces se puede comparar la configuración como highmem.

La opción convencional hasta hace pocos años era 2: 2 dividida, es decir el espacio de usuario se limita a 2GiB de espacio de direcciones, una solución fácil de programar y tiene la eficiencia decente, pero en este escenario es obvio que no puede tener su solicitaron montón, ya que no deja espacio para el texto del programa, apilar, etc. Más recientemente, la tendencia ha sido de 3: 1 (similar al cambiar de ventana / 3GB) que amplía el espacio de direcciones del espacio de usuario a costa de abarrotar el propio núcleo del sistema operativo en un menor espacio que potencialmente causa sus propios problemas. Esto podría funcionar, pero sería muy pequeña, así que también no se sorprendería si no funciona para sus puestos de trabajo. Finalmente los nuevos núcleos también ofrecen una opción donde se obtiene el espacio de usuario 4GiB de 32 bits, lo que podría ser suficiente para hacer que sus trabajos se ejecutan de forma fiable, a un costo significativo desempeño desde entonces, evidentemente, las direcciones del espacio de usuario y el kernel no pueden co-existir.

Para probar esto se necesitaría un nuevo kernel. Es posible que pueda instalar sólo uno proporcionado por SuSE (ver si ofrecen otros para elegir, por ejemplo, una opción "PAE") o puede que tenga que compilar su propia, en cuyo caso es probable que invalida su contrato de soporte.

Pero, en realidad, sólo debe ir con la opción 1, cambiar a una JVM de 64 bits y poner los pies en alto.