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:

• What is the Page File for anyway?
• Guidance on page file size X64 and X32 machines Windows 2003 servers
• Configuring paging files for optimization and recovery in Windows Server 2003, in Windows 2000, and in Windows NT
• Optimizing Operating System Performance
• Performance Tuning Guidelines for Windows Server 2008
• https://www.petri.co.il/pagefile_optimization.htm

¿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

• Anonymous
  January 01, 2003
  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

• Anonymous
  January 01, 2003
  Hola dnk Grandes huchas no hacen grandes ahorros. :-) Saludos

• Anonymous
  January 01, 2003
  The comment has been removed

• Anonymous
  February 05, 2009
  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.

• Anonymous
  February 05, 2009
  The comment has been removed

• Anonymous
  February 06, 2009
  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!!!

• Anonymous
  February 06, 2009
  Update!! algún Vaio y algún Asus sí lo soportan