Hay casos en los que es interesante observar la memoria inactiva, una alta proporción de memoria activa e inactiva puede indicar presión de la memoria, por ejemplo, pero esa condición suele ir acompañada de paginación/intercambio, que es más fácil de entender y observar. El archivo /proc/kpageflags contiene un mapa de bits de 64 bits para cada página de memoria física, puede obtener un resumen con page-types que puede venir con su núcleo.
Su comprensión de activo e inactivo es incorrecto sin embargo
- memoria activa son páginas a las que se ha accedido "recientemente"
- memoria inactiva son páginas a las que no se ha accedido "recientemente"
"recientemente" no es una medida absoluta de tiempo, sino que también depende de la actividad y la presión de la memoria (puede leer algunos de los detalles técnicos en el libro gratuito Understanding the Linux Virtual Memory Manager , el Capítulo 10 es relevante aquí), o la documentación del núcleo (pagemap.txt).
Cada lista se almacena como una LRU (más o menos). Las páginas de memoria inactiva son buenas candidatas para escribir en el archivo de intercambio, ya sea de manera preventiva (antes de que se requieran páginas de memoria libre) o cuando la memoria libre cae por debajo de un límite configurado y se necesitan (inminentemente) páginas libres.
Cualquier indicador se aplica a las páginas asignadas a los procesos en ejecución, con la excepción de la memoria persistente o compartida, toda la memoria se libera cuando finaliza un proceso; de lo contrario, se consideraría un error.
Este marcado de página de bajo nivel no necesita conocer el PID (y una página de memoria puede tener más de un PID con él asignado en cualquier caso), por lo que la información requerida para proporcionar los datos que solicita no está en un solo lugar.
Para hacer esto por proceso, debe extraer los rangos de direcciones virtuales de /prod/PID/maps , convertir a PFN (página física) con /proc/PID/pagemap e indexar en /proc/kpageflags . Todo está descrito en pagemap.txt , y ocupa entre 60 y 80 líneas de C. A menos que esté solucionando problemas del sistema VM, los números no son muy interesantes. Una cosa que podría hacer es contar las páginas inactivas y respaldadas por intercambio por proceso, estos números deberían indicar procesos que tienen un tamaño de RSS (residente) bajo en comparación con VSZ (tamaño total de VM). Otra cosa podría ser inferir una fuga de memoria, pero existen mejores herramientas para esa tarea.
No existe tal herramienta, ya que es completamente inútil para cualquier programa externo.
La única parte del sistema que necesita saber eso es el controlador de memoria del núcleo, que lo usará para saber qué paginar (intercambiar) si se queda sin memoria disponible.
El único caso relacionado que podría causar alguna preocupación es si su intercambio se llena casi por completo. Si ese llega a ser el caso, simplemente auméntelo.
Nunca he visto problemas reales que impliquen investigar en memoria inactiva.