Mit ps
oder ähnlichen Tools erhalten Sie nur die Anzahl der vom Prozess allokierten Speicherseiten. Diese Zahl ist korrekt, aber:
-
spiegelt nicht die tatsächliche Menge an Speicher wider, die von der Anwendung verwendet wird, sondern nur die für sie reservierte Menge an Speicher.
-
kann irreführend sein, wenn Seiten gemeinsam genutzt werden, z. B. durch mehrere Threads oder durch die Verwendung von dynamisch verknüpften Bibliotheken.
Wenn Sie wirklich wissen möchten, wie viel Speicher Ihre Anwendung tatsächlich verwendet, müssen Sie sie mit einem Profiler ausführen. Zum Beispiel kann Ihnen Valgrind Einblicke in die verwendete Speichermenge geben und vor allem mögliche Speicherlecks in Ihrem Programm aufzeigen. Das Heap-Profiler-Tool von Valgrind heißt 'massif':
Massif ist ein Heap-Profiler. Er führt eine detaillierte Heap-Profilerstellung durch, indem er regelmäßig Schnappschüsse des Heaps eines Programms aufnimmt. Er erstellt einen Graphen, der die Heap-Nutzung im Laufe der Zeit zeigt, einschließlich Informationen darüber, welche Teile des Programms für die meisten Speicherzuweisungen verantwortlich sind. Der Graph wird durch eine Text- oder HTML-Datei ergänzt, die zusätzliche Informationen zur Bestimmung des Ortes enthält, an dem der meiste Speicher allokiert wird. Massif führt Programme etwa 20x langsamer als normal aus.
Wie in der Valgrind-Dokumentation erklärt, müssen Sie das Programm durch Valgrind ausführen:
valgrind --tool=massif
Massif schreibt ein Dump von Speichernutzungsschnappschüssen (z. B. massif.out.12345
). Diese bieten (1) einen Zeitplan der Speichernutzung, (2) für jeden Schnappschuss einen Bericht darüber, wo im Programm Speicher allokiert wurde. Ein großartiges grafisches Tool zur Analyse dieser Dateien ist massif-visualizer. Aber ich fand ms_print
, ein einfaches textbasiertes Tool, das mit Valgrind geliefert wird, bereits sehr hilfreich.
Verwenden Sie zur Suche nach Speicherlecks das (standardmäßige) memcheck
-Tool von Valgrind.
Neuere Tools, die ich selbst noch nicht ausprobiert habe, sind HeapTrack und der Heap-Profiler in gperftools.
11 Stimmen
Diese Frage gehört wahrscheinlich heutzutage eher auf serverfault.com, obwohl es mir sagt, dass sie "zu alt zum Migrieren" ist. Möchte es allerdings nicht wirklich scließen...
0 Stimmen
Beziehen Sie sich auf diese Frage. stackoverflow.com/questions/669438/…
4 Stimmen
Tatsächlich zeigt
ps
nicht einmal das - es zeigt virtuelle und residente Speicherzahlen, wobei virtuelle die maximale Menge an Speicher ist, die der Prozess theoretisch nutzen könnte, wenn er der einzige Prozess wäre (niemals so), jede einzelne Seite, die er allokiert hat, verwendet (nie passiert) und keine Seiten abbildet oder abbildet oder entmappen (unwahrscheinlich). Während residente anzeigt, wie viel virtueller Speicher gerade physisch zugeordnet ist. Normalerweisevirt > Nutzung > res
jedoch auf einem 64-Bit-Systemvirt ~= res*10
ist es eine sehr große Bandbreite.9 Stimmen
Der Auszug aus dem verlinkten Artikel ist totaler Unsinn. Der RSS ist der tatsächlich verwendete physische Speicher, und der VSZ übersetzt möglicherweise nicht in die Verwendung von physischem Speicher, auch wenn der Prozess der einzige war, der lief.