Es gibt Fälle, in denen es interessant ist, den inaktiven Speicher zu betrachten. Ein hohes Verhältnis von aktivem zu inaktivem Speicher kann beispielsweise auf Speicherdruck hinweisen, aber dieser Zustand wird normalerweise von Paging/Swapping begleitet, was einfacher zu verstehen und zu beobachten ist. Die Datei /proc/kpageflags enthält ein 64-Bit-Bitmap für jede physikalische Speicherseite, eine Zusammenfassung erhalten Sie mit page-types die möglicherweise mit Ihrem Kernel geliefert werden.
Ihr Verständnis von aktiv und inaktiv ist jedoch falsch
- aktiver Speicher sind Seiten, die "kürzlich" aufgerufen wurden
- inaktiver Speicher sind Seiten, die "kürzlich" nicht aufgerufen wurden
"kürzlich" ist kein absolutes Zeitmaß, sondern hängt auch von Aktivität und Speicherauslastung ab (einige technische Details können Sie im kostenlosen Buch Understanding the Linux Virtual Memory Manager nachlesen , Kapitel 10 ist hier relevant) oder die Kernel-Dokumentation (pagemap.txt).
Jede Liste wird als LRU (mehr oder weniger) gespeichert. Inaktive Speicherseiten sind gute Kandidaten zum Schreiben in die Auslagerungsdatei, entweder präventiv (bevor freie Speicherseiten benötigt werden) oder wenn der freie Speicher unter eine konfigurierte Grenze fällt und freie Seiten (unmittelbar) benötigt werden.
Beide Flags gelten für Seiten, die laufenden Prozessen zugewiesen sind, mit Ausnahme von persistentem oder gemeinsam genutztem Speicher wird der gesamte Speicher freigegeben, wenn ein Prozess beendet wird, andernfalls würde dies als Fehler betrachtet werden.
Diese Seitenmarkierung auf niedriger Ebene muss die PID nicht kennen (und eine Speicherseite kann auf jeden Fall mehr als eine PID haben, die ihr zugeordnet ist), sodass die Informationen, die zum Bereitstellen der von Ihnen angeforderten Daten erforderlich sind, nicht an einem Ort sind.
Um dies pro Prozess zu tun, müssen Sie die virtuellen Adressbereiche aus /prod/PID/maps extrahieren , mit /proc/PID/pagemap in PFN (physische Seite) konvertieren , und indexieren Sie in /proc/kpageflags . Das alles ist in pagemap.txt beschrieben , und dauert etwa 60-80 Zeilen C. Wenn Sie keine Fehler im VM-System beheben, sind die Zahlen nicht sehr interessant. Eine Sache, die Sie tun könnten, ist, die inaktiven und durch Swap gesicherten Seiten pro Prozess zu zählen. Diese Zahlen sollten Prozesse anzeigen, die im Vergleich zu VSZ (Gesamtgröße der VM) eine niedrige RSS-Größe (resident) haben. Eine andere Sache könnte sein, auf ein Speicherleck zu schließen, aber es gibt bessere Tools für diese Aufgabe.
Es gibt kein solches Tool, da es für jedes externe Programm völlig sinnlos ist.
Der einzige Teil des Systems, der das wissen muss, ist der Speicher-Handler des Kernels, der ihn verwendet, um zu wissen, was ausgelagert (ausgelagert) werden soll, wenn ihm der verfügbare Speicher ausgeht.
Der einzige verwandte Fall, der Sorgen bereiten könnte, ist, wenn Ihr Swap fast voll wird. Wenn das jemals der Fall sein sollte, erhöhen Sie es einfach.
Ich habe nie wirkliche Probleme gesehen, die eine Untersuchung des inaktiven Speichers beinhalteten.