¿Por qué el process Java VM consume más memory RAM especificada en el parámetro -Xmx?

Tengo varios serveres que ejecutan CentOS 5.4 y sólo una aplicación que se ejecuta en Java VM. He configurado la VM Java con los siguientes arguments:

java -Xmx4500M -server -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:NewSize=1024m -Djava.net.preferIPv4Stack=true -Dcom.sun.management.jmxremote=true 

Las máquinas en las que se ejecuta la máquina virtual tienen 6 GB de RAM y no hay otras aplicaciones en ejecución. Después de un time, el process de java comienza a golpear el espacio de intercambio realmente duro, consigo esta información del command top :

 7658 root 25 0 11.7g 3.9g 4796 S 39.4 67.3 543:54.17 java 

Por otro lado, si me conecto a través de JConsole, informa que Java VM tiene 2.6 GB utilizado, 4.6 GB comprometido y 4.6 Gb máx.

java -version devuelve:

 java version "1.6.0_17" Java(TM) SE Runtime Environment (build 1.6.0_17-b04) Java HotSpot(TM) 64-Bit Server VM (build 14.3-b01, mixed mode) 

¿Por qué la VM Java se está expandiendo tanto más allá de su tamaño de montón? ¿Y dónde va esa memory, si no se informa en JConsole?

He notado un error en algunas aplicaciones comerciales basadas en Java, donde la aplicación se comporta bien en 32 bits de Java, pero requiere un extra (y casi innecesario) 1.25GB sólo para empezar a usar Java de 64 bits. Así que lo que tarda 256 MB en Java de 32 bits toma 1,5 GB en un time de ejecución de 64 bits.

Sospecho que Java está reportando lo que piensa que la aplicación está usando, pero no su propio time de ejecución, sobre todo en el caso en que se invoca este error.

Podría intentar ejecutar la aplicación en un time de ejecución de 32 bits, o volver al soporte técnico del proveedor (puede costar $$) y preguntar qué hay.

En última instancia, si logras limitar la huella de memory total, sólo obligas a que la aplicación se bloquee antes y te queda un problema.

-Xmx es la cantidad máxima de espacio de montón que está utilizando el vm. No incluye memory para las classs cargadas, el propio vm o stacks de subprocesss o la memory utilizada para el JIT por ejemplo. La línea de arriba también es engañosa ya que el primer número incluye memory compartida que es utilizada por otros progtwigs también. El segundo nummer 3.9g es el tamaño residente y más cercano a la realidad.

Mi recomendación: Compruebe si realmente necesita ese montón (número y tamaño de objects) y networkinguzca el número -Xmx si puede.