Paginación y máquinas virtuales


Hola

Realmente el post anterior era para poder poner este. En una máquina virtual, ¿cómo dimensiono la memoria y los ficheros de paginación?. Pues igual que lo harías en una máquina física. Iba a ponerme manos a la obra a escribir al respecto del pagefile.sys, pero visto lo que he encontrado ya escrito, gran parte me la puedo ahorrar:

¿Es buena la paginación?. Ni buena ni mala, es normal. Es un mecanismo al que hay que recurrir para poder repartir el espacio de direccionamiento de memoria de cada uno de los procesos entre las direcciones de memoria físicas de la RAM existente. Lo que es malo es la excesiva paginación, que suele ser el síntoma claro de que necesitamos otorgar más memoria física a una máquina, o que tenemos que bucear entre los procesos en ejecución en busca de algún tipo de "leak" (muy gráfico eso del "goteo de memoria").

La excesiva paginación es problemática en entornos de virtualización porque supone la superposición de dos cosas. Es finalmente el Hypervisor el que debe gestionar todas las operaciones de acceso a memoria que quieren efectuar las máquinas virtuales, y por otro lado supone un aumento del I/O a disco que suele ser directamente proporcional al número de VMs . Por tanto, si en un entorno físico es importante, en un entorno virtual atinar con la combinación entre la RAM asignada a una VM, con el tamaño necesario del fichero de paginación, y con cómo las operaciones de lectura/escritura se reparten entre el sistema de almacenamiento físico es crucial para ganar o perder unos cuantos puntos de rendimiento.

Si existiera una receta universal para la configuración de la memoria y el tamaño del fichero de paginación, el "Performance Tuning" dejaría de ser un arte. Lo más parecido puede encontrarse en el capítulo dedicado a la gestión de memoria dentro del libro "Windows Internals" de Mark Russinovich. Este es el resumen:

Los contadores "Memory: Commited Bytes", "Memory: Commit Limit", "Paging File: % Usage" y "Paging File: % Usage Peak" pueden ayudar a la hora de determinar el tamaño del fichero de paginación. Aunque todas las recomendaciones suelen usar una función de la RAM (entre x1,5 y x3) para definir su tamaño, también es cierto que a mayor cantidad de memoria física, menor probabilidad de que una página tenga que ser trasladada al fichero de paginación. Para determinar la cantidad aproximada que podrían llegar a necesitar las aplicaciones corriendo en un servidor, basta dejar el servidor funcionando un cierto tiempo y examinar el campo "Peak Commit Charge" (en el Task Manager o con el Process Explorer). Este numero representa el tamaño máximo del fichero de paginación que hubiera sido necesario si el sistema hubiese paginado a la vez toda la memoria virtual, cosa que no suele suceder. También hay una relación en el Task Manager que es el Commit Charge / (RAM+Tamaño del fichero de paginación) que nos indica la cantidad de espacio del fichero de paginación que se puede llegar a usar en un momento dado si el sistema paginara de golpe toda la memoria virtual en uso.

Además de con herramientas como el Task Manager, el Performance Monitor o el Process Explorer, estas dos cifras se pueden obtener también rápidamente así:

> wmic path Win32_PerfFormattedData_PerfOS_Memory get CommittedBytes,CommitLimit

CommitLimit  CommittedBytes
17238245376  7058923520

Por otro lado, para ver el uso que se está haciendo del fichero de paginación (los resultados son en MB):

> wmic path Win32_PageFileUsage get allocatedbasesize,currentusage,peakusage

AllocatedBaseSize  CurrentUsage  PeakUsage
8425                       94                    102

Si, esto es complicado de entender. También esta explicado aqui

MORALEJA:

  • Si eres rácano con la RAM que asignas a la VM, puede que tengas que aumentar su fichero de paginación y el rendimiento del la VM bajará. Además probablemente afectará a las demás, por el exceso de I/O que supondrá sobre el sistema de almacenamiento.
  • A mayor RAM asignada a la VM, menor paginación y (en general) menor tamaño de fichero de paginación necesario.
  • Pensar que definir el menor tamaño posible para el fichero de paginación aumentará el rendimiento porque disminuiremos el I/O es un error. Si lo dejamos pequeño y de tamaño fijo, aumentaremos las posibilidades de obtener el famoso mensaje de "sus sistema tiene poca memoria virtual disponible". Si lo ponemos pequeño, pero lo dejamos crecer, su continuo crecimiento producirá una perdida adicional de rendimiento.
  • Procura ajustar la cantidad de RAM de manera que sea el mayor tiempo posible mayor que el Commit Charge (es decir, busca el "Peak Comit Charge")

Saludos

David Cervigón

Comments (7)
  1. Hola Pedro

    Lo importante es ver que micro, y luego comprobar que capacidades tiene en http://processorfinder.intel.com/Default.aspx

    Si quieres que te recomiende alguno de los que yo he probado en persona, mandame un correo y dime tu presupuesto

    Saludos

  2. Hola dnk

    Grandes huchas no hacen grandes ahorros. 🙂

    Saludos

  3. Hola Jose Luis

    Un honor que te pases a comentar por aqui

    Estuve tentado en hacer mención al memory overcommit, pero no queria que nadie me pudiera tachar de (más) tendencioso.

    Cualquier técnica que implique repartir entre las VMs más memoria de la que realmente hay físicamente en el host lleva asociada otra para controlar la situación en caso de que la cosa se desmadre y a todo el mundo le de por consumir a la vez. Las cosas se suelen diseñar en entornos de produción de forma que esto suele ocurrir, ya que se supone que cada máquina esta dimensionada para hacer su trabajo a pleno rendimiento (los coches se compran, la mayoría de las veces, para otra cosa que tenerlos aparcados en el garage). Las técnicas de ballooning precisamente lo que hacen es que ese "Commit Charge" que podría ser potencialmente paginado, acabe siéndolo a la fuerza, de manera que la memoria quede libre para otro proceso de esa o de otra VM. Eso supone dos cosas. La no deseable excesiva paginación en la VM, y una sobracarga en la propia operativa de gestión de la memoria (y a su vez paginación) del host. No seré yo quien le niegue su valor a cualquier tipo de virguería tecnológica, siempre y cuando se pongan las cosas en su justo contexto 🙂

    Saludos

  4. J. L. Medina says:

    Puestos a ser agnósticos…

    Tal y como nos cuenta David, el paginado es poco menos que inevitable. El paginado de Memoria a disco, o swap, es un mecanismo que nos defiende a todos los ignorantes que trabajamos en esto del famoso "memory overflow" de otros tiempos. Lo sé, sé que esto no es exacto, pero sí aproximado.

    No hace mucho, cierto virtualizador (me ha dado por denominar así a quien piensa que el mundo virtual es la panacea) me comentaba que, como con ESX tiene memory overcommit, podría eliminar el swap file. Mi respuesta fué: El swap no lo decide el hardware (y para mí una VM es hard), sino el OS. El interfecto me comentaba que ya que ESX hacía overcommit, simplemente le bastaba con asignar más memoria de la que la VM fuera a usar, así que consecuentemente no necesitaría swap.

    Para quien piense así, lamento decepcionarle: No es la configuración de la VM la que decide si hay swap o no: Es el sistema operativo. Y para cualquiera, el tener o no fichero/área de swap significa cierta comodidad… básicamente porque están diseñados para contar con él.

    El mundo real es muy parecido al virtual salvo en el botón de power.

    ¿A qué viene esto? a que el post del maestro Cervigón dice verdades como puños.

    Un saludo.

  5. dnk says:

    Hola,

    En todos los artículos que he leido hablan de ajustar el tamaño para un mejor rendimiento. Pero no he visto ninguna referencia sobre el uso de archivos de paginación excesivos. Por ejemplo: Sobre una máquina con 1Gb de RAM asignar un archvo de 4Gb de maximo y minimo.

    En la mayoria de casos será excesivo, pero, ¿tiene alguna penalización? (sin contar el evidente derroche de espacio)

    PS. Lo tipico, enhorabuena por el blog. Llevo siguiendote bastante tiempo y me parece genial. 🙂

  6. Pedro says:

    Buenas perdoname por poner aquí este -offtopic-

    Mira una cosa, quiero cambiar de portátil, pero deseo comprar uno que me soporte el Hiper-V , el caso es que he llamado a varios distribuindores a nivel nacional para que me asegurasen que equipos soportan tal tecnológia y me he sorprendido al ver que ninguno me supo decir una u otra cosa.

    Si pudieses a consejarme, u horientarme, he mirado Dell, Asus, Lenovo, aún no he llamado a HP pero es que ya me lo veo venir.

    Un Saludo!!!

  7. Pedro says:

    Update!! algún Vaio y algún Asus sí lo soportan

Comments are closed.

Skip to main content