Buscar
Social
IntelliJ IDEA

Contenido de otras web
« Resultados de la encuesta: ¿Crees que JavaFX es el futuro del escritorio en la plataforma Java? | Main | La semana pasada en javaHispano »
lunes
nov262012

¿Uso una máquina virtual de 32 o de 64 bits?

En este interesante artículo se discuten algunos de los pros y cons de emplear una máquina virtual de 32 o de 64 bits. La principal ventaja de irse a los 64 bits es la posibilidad de emplear más memoria para el heap, que en una máquina de 32 bits, dependiendo del sistema operativo, tiene un tamaño máximo de 1.5GB en Windows (aunque hackeando un poco podemos llegar a los 3GB), 2 GB en Linux y 3.8GB en Mac OS X.

Sin embargo, esa memoria extra no viene "gratis". Al correr nuestra aplicación en una máquina virtual de 64 bits la aplicación va a emplear más memoria para hacer lo mismo. Según la experiencia del autor, nuestra aplicación va a requerir entre un 30 y el 50% más de heap que la misma aplicación corriendo en una máquina virtual de 32 bits. El motivo de esto es que las cabeceras de los objetos en las máquinas virtuales de 32 bits son de 8 bytes, mientras que en las máquinas virtuales de 64 bits son de 12 bytes. Además, las referencias a objetos en las máquinas de 32 bits son siempre de 4 bytes, mientras que en las máquinas de 64 bits pueden ser de 8 bytes.

Un heap más grande no significa sólo gastar más memoria RAM, sino que significa también que el recogedor de basura va a necesitar más tiempo para hacer su trabajo, lo cual puede introducir pausas excesivamente largas en la aplicación, y disminuye el rendimiento global de la aplicación.

De todo ello se deriva que, salvo que nos haga falta más memoria de la que es posible emplear en la máquina virtual de 32 bits, lo mejor es emplear una máquina virtual de 32 bits. Pero si necesitamos más memoria, no nos queda más remedio que ir a la máquina de 64 bits.

¿Alguno de vosotros ha usado vosotros alguna vez una máquina virtual de 64 bits? ¿qué tal la experiencia?

PrintView Printer Friendly Version

EmailEmail Article to Friend

Reader Comments (7)

En máquinas con -d64 activado, si usas menos de 26G de heap, se recomienda usar
XX:+UseCompressedOopts que comprime esas cabeceras que indicabas que en 64bits se disparan.

Dicen que el overhead acaba produciendo un impacto menor del 10% en rendimiento con respecto a 32bits.

Un saludo

noviembre 26, 2012 | Unregistered CommenterDavid Canos

Para el uso de BAM como Apama, donde todos los datos correlacionados se mantienen en memoria RAM ha sido imprescindible usar 64bit, sino no cubríamos ni el 20% de los datos que teníamos que monitorizar...

Aunque realmente fue por exigencias de la herramienta, si hubiera sido más flexible pudiendo hacer cierta paginación en disco duro, como StreamBase or incluso, de otra forma, con el BAM de Oracle, quizás con una máquina de 32bit hubiera bastado.

Últimamente, usado Oracle SOA+BPM, etc.., también se hace casi indispensable, o le damos 8gigas por VM o el sistema no tira.., aunque sobre todo en el tema de muchos (centenares de) usuarios ADF concurrentes reales en el BPM, a pesar del clustering y demás.

Saludos.

noviembre 26, 2012 | Registered Commenterasertus

En mi mac os x con i7 a 2.3ghz y 8gb de ram trabajo habitualmente con VMware Fusion (última versión normalmente) y máquinas de 32 y 64b, tanto windows como linux.

Los servidores que me creo Debian suelen ser 64b (con poca ram y poco uso, suelen ser servidores web o repositorios svn/git), en cambio el entorno de desarrollo suelo crearlo de 32b por lo que expongo a continuación.

Lo que experimenta mi pc con 2 máquinas de 64b funcionando, con windows 7 profesional 64b o ultimate, con 3 gb de ram cada una, habiendo quitado la escritura en disco de la memoria (parametrizado en el .vmx) y al sistema operativo guest quitado la hiberanción y fichero de paginación, es que la CPU se dispara, a cualquier movimiento que se hace.

Exáctamente el mismo contexto con 32b es mucho más fluido. Y menos ruidoso, puesto que los ventiladores no se suelen encender.

Mi conclusión es que si virtualizamos, y no necesitamos 64b por algo muy concreto, como por ejemplo desarrollar JNI de 64b (atacando a librerías nativas 64b), me quedo con 32b.
Mi particular sensación también, en concreto en mi máquina es que es bastante más fluido en igualdad de condiciones.

A la hora de virtualizar un servidor que intente replicar un entorno, como integración o producción, evidentenmente 64b, sople lo que sople :). Pero si no es así... ;)
Quizás es algo en concreto de mi arquitectura o micro.

Aunque es un poco subjetiva mi aproximación, quizás tenéis experiencias similares.
Cualquier crítica o dato que me aportéis os lo agradezco.

Un saludo a todos!

noviembre 27, 2012 | Unregistered Commenterfranferri

Tengo un cluster de dos nodos idénticos sirviendo las mismas aplicaciones, balanceados tras unos apache que envían el tráfico al ~50% a cada nodo. He puesto uno de los nodos con 32b y el otro con 64b y cuando se estabilice el consumo de memoria, veremos si hay algo que llame la atención.

De momento, lo único visible es que el proceso de S.O. de 32b consume ~7% menos de memoria, y que el permgen en 32b ocupa un 17% menos, aunque como no han tenido "un ciclo completo de carga", todavía es pronto para decir nada.

Seguiremos la pista.

noviembre 27, 2012 | Unregistered CommenterGuatdefu

@David Canos: Por cierto que leyendo la documentación de cambios/rendimiento, esa opción que mencionas ya está puesta por defecto en el JDK7 y JDK6 a partir de una revisión, para heaps menores de 32GB.

Así que como mi heap es bastante menor, es normal que me salgan tan pocas diferencias.

noviembre 27, 2012 | Unregistered CommenterGuatdefu

Después de 1 día entero en marcha, la única diferencia notable es un consumo de PermGen alrededor de un 20% menor en la máquina de 32b. En el resto de consumos, ronda lo anecdótico y hasta se consume más memoria Heap en la maquina de 32b, posiblemente por cuestión casual de carga...

Así que en nuestro caso no parece que sea algo "crítico". Habría que realizar otras pruebas para ver si hay otras ventajas o desventajas en cuanto a rendimiento u otros factores, pero por consumo de memoria, solo por el PermGen... que en Java 8 desaparecerá :D

noviembre 28, 2012 | Unregistered CommenterGuatdefu

Por cierto, en MacOS no hay opcion de ejecutar java 1.6 y mayores con 32 bits!

noviembre 29, 2012 | Registered Commentergolthiryus

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Post:
 
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>