Muchas veces hemos leído páginas Web en las que nos recomiendan tener el doble que la memoria RAM disponible, y otras en las que ese concepto se adecuaba cuando la RAM era escasa, pero con más de 2GB de RAM, con 2GB en la swap era suficiente. La verdad es que con los discos grandes que hay ahora, y teniendo en cuenta de que para el sistema en Linux rara vez llegamos a más de 8GB, en general tengo una tendencia a dejar alrededor de 4GB en la RAM. Aun así, seguimos sin saber cuál es la cifra más adecuada. Pues lo voy a complicar más.
Yo uso en mi trabajo SPSS para hacer estadística, lo que supone una máquina virtual con un sistema huesped Windows XP. En ocasiones Windows funciona muy lentamente, de manera exasperante. La razón es muy simple; cuando funciona tan lentamente el sistema husped está realmente en la swap, en el disco duro, y no directamente en la RAM, y por tanto el tráfico desde el disco virtual hasta la ejecución supone un retraso importante. En todos estos ordenadores que vamos a ver ahora se ejecuta Ubuntu 10.10 o 10.04; la máquina virtual se basa en VirtualBox 4.04, con un sistema huesped Windows XP SP3. Veamos los resultados:
1. Ordenador de trabajo con 2GB de RAM, lo que supone que la RAM asignada a la máquina virtual para ejecutar Windows XP es 768MB. El resultado de la ejecución de la máquina virtual y SPSS, medido mediante conky, fue:
Como vemos la RAM está completamente ocupada y fue necesario acudir a la swap. Del total de 3.81GB, se ocupan 630MB. Como se puede ver en la parte inferior, VirtualBox supone el mayor consumo de memoria.
2. El segundo experimento fue en un ordenador con más RAM. Cierto es que aunque tiene 4GB de RAM es un ordenador más "viejo". De estos 4GB, el sistema huesped tiene asignados 1,536GB para él. Vamos a ir viendo el efecto paso a paso:
- Primero la ejecución de VirtualBox e inicio de un sistema huesped con Windows XP. Como vemos se ocupa ya un total de 1,22Gb de la swap (la realización de las ejecuciones era lentísima) y un gran consumo de RAM, como es natural, por la máquina virtual
Después, para ver todo el efecto posible, se ejecutó en el sistema hospedador un programa muy consumidor de recursos, como aMule, y en el sistema huesped SPSS. Aquí saltaron las alarmas, por que sobrepasamos en la swap los famosos 2 GB que se señalan como óptimos en algunos sitios; se llegó a un máximo de 2,15GB de swap utilizada. De nuevo se observa el gran consumo en RAM de VirtualBox, en este caso sumado al de aMule. La idea era conectar posteriormente jDownloader, ya que la ejecución a través de Java supone un gran consumo de recursos, pero el sistema en ese momento estaba a punto del colapso y decidimos no seguir.
Por supuesto, esto tiene solución. La solución es más RAM.
3. Ordenador nuevecito con 16GB de RAM. El sistema hospedador sigue siendo Ubuntu 10.10 con un kernel PAE, lo que significa que utiliza la RAM en conjuntos de un máximo de 4GB por aplicación. Cada sistema huesped tiene asignado en este caso 4GB. Secuencialmente los resultados fueron:
- En primer lugar, recien iniciado el sistema hospedador y añadido solo al arranque Firestarter y Conky (la mancha azul de la izquierda es el terminal de ejecución de conky):
- Ejecución de los programas habituales (Firefox, un cliente correo, Nautilus y Google gadgets)
- Ejecución de VirtualBox y conexión a un sistema huesped (Windows XP), que lleva a sobrepasar el uso de 4GB de RAM, pero la swap sigue vacía
- Conexión de un segundo sistema huesped (2 Windows XP simultáneamente), y ejecución de SPSS y Word en los dos, actualización en ambos del antivirus (AVIRA) y de Spybot. Es de suponer, pero no se comprobó, que cada Windows estaría buscando sus actualizaciones. Se sobrepasan 8GB usados en la RAM pero la swap sigue vacía. Como observación personal, estos Windows XP parecen funcional más rápido que en una instalación directa en disco duro e otros ordenadores; en teoría eso no puede ser así, pero es una sensación.
En este caso, en este ordenador con 16GB de RAM, la swap no fue utilizada en ningún momento; incluso el uso de la RAM fue relativamente bajo, teniendo en cuenta que los porcentajes que vemos aquí son sobre 16GB.
Conclusión: la lentitud en las máquinas virtuales se debe fundamentalmente a que una falta de RAM genere que los sistema huesped esté realmente almacenándose en la swap. La solución es fácil y bastante barata en este momento, ya que 8GB de RAM no cuestan hoy muy por encima de 60-75€, y es simplemente añadir más RAM. El problema es que lo admita nuestras placas, sobre todo en ordenadores de más de 2,5-3 años.
por lo regular siempre uso lo mismo que tengo de mi RAM osea 2gb en swap XD no veo la necesidad de mas sinceramente ademas de ser una notebook.
ResponderEliminarsalu2
Este comentario ha sido eliminado por el autor.
ResponderEliminarLa necesidad nace de las aplicaciones que usas. En mi notebook, sin disco duro, donde utilizo lápices con Ubuntu o Slax y ahora estoy preparando uno con Debian, me conformo con 128 o 256MB de swap (siempre es bueno dejar algo). Sin embargo, en ordenadores con discos muy grandes (por ejemplo uso un disco de 1,5TB como home, y otro de 30GB para sistema, del que nunca Linux llega a ocupar 10GB), que más nos da dejar 4 u 8GB de swap, aunque no se utilicen. Esta entrada se hizo por que esa cantidad recomendada de 2GB es suficiente... si no usas máquinas virtuales, ya que estas bloquean una parte fija de la RAM, y si precisan más memoria, que en el caso de Windows es siempre, recurren a la swap, con lo que ese estándar de 2GB no es suficiente. He llegado solo con un Windows XP y SPSS hasta consumir 2,65GB de la swap, produciéndose un enlentecimiento del análisis estadístico. Ahora procuro hacer los análisis con R, pero aun tengo que aprender mucho más, y tengo un ordenador con 16GB de RAM, lo que hace que le pueda dedicar a un sistema virtual 4GB, que es más de lo que puede usar, y no recurre a la swap.
ResponderEliminarEste comentario ha sido eliminado por el autor.
ResponderEliminarEste comentario ha sido eliminado por un administrador del blog.
ResponderEliminarEste comentario ha sido eliminado por un administrador del blog.
ResponderEliminar