Comprender el uso de memoria virtual> intercambio + físico en Linux

Tengo un proceso que informa en la parte superior que tiene 6 GB de memoria residente y 70 GB de memoria virtual asignada. Lo extraño es que este servidor en particular solo tiene 8 GB físicos y 35 GB de espacio de intercambio disponible.

Del manual 'superior':

   o: VIRT  --  Virtual Image (kb)
      The total amount of virtual memory used by the  task.   It  includes
      all  code,  data  and  shared  libraries  plus  pages that have been
      swapped out. (Note: you can define the STATSIZE=1 environment  vari-
      able  and  the VIRT will be calculated from the /proc/#/state VmSize
      field.)

      VIRT = SWAP + RES.

Dada esta explicación, esperaría que la asignación de memoria virutal para un proceso se limite a mi intercambio + memoria física disponible.

Según 'pmap', el código, la biblioteca compartida y las secciones de memoria compartida de este proceso son mínimas, no más de 300M más o menos.

Obviamente, la máquina y el proceso siguen funcionando correctamente (aunque lentamente), entonces, ¿qué me estoy perdiendo aquí?

Puede ser demanda cero memoria que no está en RAM física, o en el archivo de paginación.

Algunos recursos que quizás desee ver:

• http://www.gitam.edu/eresource/comp/gvr(os)/13.6.htm
• http://linux.derkeiler.com/Newsgroups/comp.os.linux.development.system/2006-11/msg00176.html

¿Su aplicación crea muchas páginas de memoria vacía? Si es así, su aplicación podría beneficiarse enormemente de:

• http://code.google.com/p/compcache/ ( EXPERIMENTAL )

Le permite comprimir y descomprimir en páginas de memoria en tiempo real. A su vez, puede mantener todo en la RAM en lugar de cambiarlo al disco ( muy lento ).

Aquí hay una discusión de virt vs. memoria residente:

/programming/561245/virtual-memory-usage-from-java-under-linux-too-much-memory-used

La discusión se refiere a los procesos de Java, pero es aplicable a cualquier cosa que se ejecute en Linux. El punto principal con respecto a virt es que el total incluye un montón de cosas que nunca se pueden usar. Virt es algo a tener en cuenta para los sistemas operativos de 32 bits (ya que los procesos alcanzarán límites en el espacio direccionable), pero de otra manera no es útil. Como se señaló, lo que debe prestarse atención es la memoria residente, que se limitará a la RAM física disponible y su intercambio.

Esto es probable porque el espacio de direcciones del proceso es del tamaño que usted indicó, pero el sistema operativo no lo asigna realmente.

De: http://lwn.net/Articles/428100/

En el proceso de tratar de alcanzar ese objetivo de "sobrecarga lo suficientemente baja y sin latencia significativa", los desarrolladores de Go han hecho algunas suposiciones simplificadoras, una de las cuales es que la memoria que se administra para una aplicación en ejecución proviene de una sola, prácticamente contigua rango de direcciones Tales suposiciones pueden encontrarse con el mismo problema que su editor encontró con vi: otro código puede asignar piezas en el medio del rango, por lo que los desarrolladores de Go adoptaron la misma solución: simplemente asignan toda la memoria que creen que podrían necesitar (pensaron, razonablemente, que 16 GB deberían ser suficientes en un sistema de 64 bits) en el momento del inicio.

Entonces, esa es la manera poco elegante de administrar la memoria a veces: tener un espacio de direcciones continuo simplifica la liberación de mem no utilizados.

La respuesta es probablemente MMAP: los datos están en el disco, pero están "fuera" del intercambio y no se pueden ver con el comando "libre" o "superior".

Si el proceso de Java no es demasiado complicado, puedes intentar jugar con "lsof" para encontrar dónde está el archivo MMAP. Sin embargo, si este proceso de Java es complicado, será difícil ser visto.

También me sorprendió que Linux le permita asignar más memoria virtual de la que hay memoria física + espacio de intercambio, pero aparentemente ayuda al rendimiento en situaciones típicas.

Afortunadamente, hay un parámetro de ajuste del núcleo que se puede usar para cambiar el modo de contabilidad de memoria. Este parámetro es vm.overcommit_memory e indica qué algoritmo se usa para rastrear la memoria disponible. El valor predeterminado (0) usa el método heurístico y sobrecompite el sistema de memoria virtual. Si desea que sus programas reciban los errores apropiados de falta de memoria en la asignación en lugar de someter sus procesos a ejecuciones aleatorias, debe establecer este parámetro en 2.

http://www.linuxjournal.com/article/10678