¿Uso una máquina virtual de 32 o de 64 bits?
Abraham
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?
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
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.
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!
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.
@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.
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
Por cierto, en MacOS no hay opcion de ejecutar java 1.6 y mayores con 32 bits!