Linux
Unter Linux sind diese Informationen im Dateisystem /proc verfügbar. Ich bin kein großer Fan des verwendeten Textdateiformats, da jede Linux-Distribution mindestens eine wichtige Datei anzupassen scheint. Ein kurzer Blick auf die Quelle von "ps" offenbart das Chaos.
Aber hier finden Sie die Informationen, die Sie suchen:
/proc/meminfo enthält die meisten systemweiten Informationen, die Sie suchen. Hier sieht es auf meinem System so aus; ich denke, Sie sind interessiert an MemTotal , MemFree , SwapTotal und SwapFree :
Anderson cxc # more /proc/meminfo
MemTotal: 4083948 kB
MemFree: 2198520 kB
Buffers: 82080 kB
Cached: 1141460 kB
SwapCached: 0 kB
Active: 1137960 kB
Inactive: 608588 kB
HighTotal: 3276672 kB
HighFree: 1607744 kB
LowTotal: 807276 kB
LowFree: 590776 kB
SwapTotal: 2096440 kB
SwapFree: 2096440 kB
Dirty: 32 kB
Writeback: 0 kB
AnonPages: 523252 kB
Mapped: 93560 kB
Slab: 52880 kB
SReclaimable: 24652 kB
SUnreclaim: 28228 kB
PageTables: 2284 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
CommitLimit: 4138412 kB
Committed_AS: 1845072 kB
VmallocTotal: 118776 kB
VmallocUsed: 3964 kB
VmallocChunk: 112860 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
Hugepagesize: 2048 kB
Für die CPU-Auslastung müssen Sie sich ein wenig anstrengen. Linux stellt die gesamte CPU-Auslastung seit dem Systemstart zur Verfügung; daran sind Sie wahrscheinlich nicht interessiert. Wenn Sie wissen wollen, wie die CPU-Auslastung in der letzten Sekunde oder in den letzten 10 Sekunden war, müssen Sie die Informationen abfragen und selbst berechnen.
Die Informationen sind verfügbar in /proc/stat die recht gut dokumentiert ist unter http://www.linuxhowtos.org/System/procstat.htm So sieht es bei meiner 4-adrigen Box aus:
Anderson cxc # more /proc/stat
cpu 2329889 0 2364567 1063530460 9034 9463 96111 0
cpu0 572526 0 636532 265864398 2928 1621 6899 0
cpu1 590441 0 531079 265949732 4763 351 8522 0
cpu2 562983 0 645163 265796890 682 7490 71650 0
cpu3 603938 0 551790 265919440 660 0 9040 0
intr 37124247
ctxt 50795173133
btime 1218807985
processes 116889
procs_running 1
procs_blocked 0
Zunächst müssen Sie feststellen, wie viele CPUs (oder Prozessoren bzw. Prozessorkerne) im System verfügbar sind. Dazu zählen Sie die Anzahl der 'cpuN'-Einträge, wobei N bei 0 beginnt und inkrementiert. Zählen Sie nicht die 'cpu'-Zeile, die eine Kombination aus den 'cpuN'-Zeilen ist. In meinem Beispiel sehen Sie cpu0 bis cpu3, also insgesamt 4 Prozessoren. Von nun an können Sie cpu0..cpu3 ignorieren und sich nur auf die 'cpu'-Zeile konzentrieren.
Als Nächstes müssen Sie wissen, dass die vierte Zahl in diesen Zeilen ein Maß für die Leerlaufzeit ist, und daher ist die vierte Zahl in der Zeile "cpu" die gesamte Leerlaufzeit für alle Prozessoren seit dem Start. Diese Zeit wird in Linux-"Jiffies" gemessen, die jeweils 1/100 einer Sekunde betragen.
Aber Sie interessieren sich nicht für die gesamte Leerlaufzeit, sondern für die Leerlaufzeit in einem bestimmten Zeitraum, z. B. in der letzten Sekunde. Um das zu berechnen, müssen Sie diese Datei zweimal im Abstand von 1 Sekunde lesen und dann den vierten Wert der Zeile vergleichen. Zum Beispiel, wenn Sie eine Probe nehmen und erhalten:
cpu 2330047 0 2365006 1063853632 9035 9463 96114 0
Eine Sekunde später erhalten Sie diese Probe:
cpu 2330047 0 2365007 1063854028 9035 9463 96114 0
Subtrahiert man die beiden Zahlen, erhält man einen Wert von 396, was bedeutet, dass die CPU in den letzten 1,00 Sekunden 3,96 Sekunden lang im Leerlauf war. Der Trick ist natürlich, dass Sie durch die Anzahl der Prozessoren dividieren müssen. 3,96 / 4 = 0,99, und das ist der Prozentsatz des Leerlaufs: 99 % Leerlauf und 1 % belegt.
In meinem Code habe ich einen Ringspeicher mit 360 Einträgen, und ich lese diese Datei jede Sekunde. So kann ich schnell die CPU-Auslastung für 1 Sekunde, 10 Sekunden usw. bis hin zu 1 Stunde berechnen.
Die prozessspezifischen Informationen finden Sie unter /proc/pid Wenn Sie sich nicht um Ihre pid kümmern, können Sie in /proc/self nachsehen.
Die von Ihrem Prozess verwendete CPU ist verfügbar unter /proc/self/stat . Dies ist eine seltsam aussehende Datei, die aus einer einzigen Zeile besteht; zum Beispiel:
19340 (whatever) S 19115 19115 3084 34816 19115 4202752 118200 607 0 0 770 384 2
7 20 0 77 0 266764385 692477952 105074 4294967295 134512640 146462952 321468364
8 3214683328 4294960144 0 2147221247 268439552 1276 4294967295 0 0 17 0 0 0 0
Die wichtigen Daten sind hier das 13. und 14. Token (hier 0 und 770). Das 13. Token ist die Anzahl der Jiffies, die der Prozess im Benutzermodus ausgeführt hat, und das 14. ist die Anzahl der Jiffies, die der Prozess im Kernelmodus ausgeführt hat. Addiert man diese beiden Werte, erhält man die gesamte CPU-Auslastung des Prozesses.
Auch hier müssen Sie diese Datei in regelmäßigen Abständen abfragen und die Differenz berechnen, um die CPU-Auslastung des Prozesses im Laufe der Zeit zu ermitteln.
Edita: Denken Sie daran, dass Sie bei der Berechnung der CPU-Auslastung Ihres Prozesses 1) die Anzahl der Threads in Ihrem Prozess und 2) die Anzahl der Prozessoren im System berücksichtigen müssen. Wenn Ihr Single-Thread-Prozess beispielsweise nur 25 % der CPU nutzt, kann das gut oder schlecht sein. Gut auf einem Einprozessorsystem, aber schlecht auf einem 4-Prozessor-System; das bedeutet, dass Ihr Prozess ständig läuft und 100% der ihm zur Verfügung stehenden CPU-Zyklen nutzt.
Für die prozessspezifischen Speicherinformationen müssen Sie sich /proc/self/status ansehen, das wie folgt aussieht
Name: whatever
State: S (sleeping)
Tgid: 19340
Pid: 19340
PPid: 19115
TracerPid: 0
Uid: 0 0 0 0
Gid: 0 0 0 0
FDSize: 256
Groups: 0 1 2 3 4 6 10 11 20 26 27
VmPeak: 676252 kB
VmSize: 651352 kB
VmLck: 0 kB
VmHWM: 420300 kB
VmRSS: 420296 kB
VmData: 581028 kB
VmStk: 112 kB
VmExe: 11672 kB
VmLib: 76608 kB
VmPTE: 1244 kB
Threads: 77
SigQ: 0/36864
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: fffffffe7ffbfeff
SigIgn: 0000000010001000
SigCgt: 20000001800004fc
CapInh: 0000000000000000
CapPrm: 00000000ffffffff
CapEff: 00000000fffffeff
Cpus_allowed: 0f
Mems_allowed: 1
voluntary_ctxt_switches: 6518
nonvoluntary_ctxt_switches: 6598
Die Einträge, die mit "Vm" beginnen, sind die interessanten:
- VmPeak ist der maximale virtuelle Speicherplatz, den der Prozess verwendet, in kB (1024 Bytes).
- VmSize ist der aktuelle virtuelle Speicherplatz, der vom Prozess verwendet wird, in kB. In meinem Beispiel ist er ziemlich groß: 651.352 kB, also etwa 636 Megabyte.
- VmRss ist die Menge des Speichers, die in den Adressraum des Prozesses eingeblendet wurde, oder die Größe der residenten Gruppe. Diese ist wesentlich kleiner (420.296 kB, oder etwa 410 Megabyte). Der Unterschied: Mein Programm hat 636 MB über mmap() abgebildet, aber nur 410 MB davon abgerufen, und daher wurden ihm nur 410 MB an Seiten zugewiesen.
Der einzige Punkt, bei dem ich mir nicht sicher bin, ist Derzeit von meinem Prozess genutzter Swapspace . Ich weiß nicht, ob das verfügbar ist.
19 Stimmen
Die Angabe "gesamter verfügbarer virtueller Speicher" ist auf modernen Betriebssystemen bedeutungslos.
82 Stimmen
Warum ist sie bedeutungslos? Macht sie die Antwort hier ungültig? stackoverflow.com/questions/3296211/ ... bitte keine Cliffhanger in den Kommentaren, das ist keine Fernsehserie.
6 Stimmen
@MindaugasBernatavicius: Die verlinkte Frage bezieht sich auf den "gesamten physischen Speicher", der eine dem Betriebssystem bekannte Hardware-Tatsache ist. Man erhält die Summe, indem man die Größen aller Speichermodule addiert. "Verfügbarer virtueller Gesamtspeicher" hingegen, was bedeutet das überhaupt? Ist das der kombinierte virtuelle Adressraum aller Prozesse, die theoretisch erstellt werden könnten? Diese Zahl liegt bei etwa 2^80 Byte und ist damit sicherlich bedeutungslos.
5 Stimmen
@MSalters - danke für das Engagement. Ich glaube, dass die Frage, was der OP im Sinn hatte, viel freundlicher und gesünder ist, als zu behaupten, dass etwas sinnlos ist (ohne eine Erklärung). Wie Sie bemerken, gehen die Antworten auch von einer bestimmten Position in dieser Hinsicht aus: Virtueller Speicher = RAM + SWAP (oder PAGEFILE) - was eine vernünftige Annahme ist. Daraus wissen wir, dass es nicht bedeutungslos ist, da es eine bestimmte Interpretation dieses Begriffs gibt (die vielleicht nicht die technisch korrekteste ist, ein Kolloquelismus), die eine Bedeutung hat.
5 Stimmen
@MindaugasBernatavicius: Das ignoriert Memory-Mapped-Dateien und Code, der nicht ausgelagert ist. Linux hat nicht gebundene Speicherzuweisungen (nicht durch RAM oder Swap gesichert) und Windows hat nicht gebundene Stacks.
1 Stimmen
@DavidSchwartz "insgesamt verfügbarer virtueller Speicher" hat eine Bedeutung. Ich arbeite mit einem Linux-System, bei dem der virtuelle Speicher auf den physischen begrenzt ist. Der Versuch, den virtuellen Speicher darüber hinaus zu nutzen, führt zum Abbruch des Programms.
1 Stimmen
@DavidSchwartz Ohne Ihr Bedürfnis nach Beschimpfungen zu berücksichtigen, ist dies eine bewusste Politik auf großen Supercomputern. Ein echter virtueller Speicher würde die Leistung unberechenbar machen. Stellen Sie sich vor, Sie arbeiten auf 1000 Knoten und einer von ihnen wird aufgrund von Swapping langsamer. Das wäre eine grobe Verschwendung von Ressourcen. Es ist besser, den Benutzern zu sagen, dass sie sich mit den Einschränkungen abfinden und darüber nachdenken müssen, was sie tun. Wenn Sie beispielsweise einen schnellen Zugriff auf eine Datei benötigen, sollten Sie sie auf dem parallelen Dateisystem richtig strippen.
0 Stimmen
@VictorEijkhout Ich kann nicht folgen. Sie strippen also ordentlich im parallelen Dateisystem und es sind 4 GB. Warum verschwenden wir genau 4 GB RAM? Ich schätze, wenn man denkt, dass man so viel RAM hat, dass man viel davon verschwenden kann, dann kann man das wohl so sehen. Aber es wäre Wahnsinn, einen Allzweckrechner so zu konfigurieren.
0 Stimmen
@VictorEijkhout Ich kann nicht folgen. Ihr Hochgeschwindigkeits-Dateisystem erlaubt es Ihnen nicht, Dateien im Speicher abzubilden? Wie führen Sie ausführbare Dateien aus? Wie rufen Sie Bibliotheken auf? Wie führen Sie mathematischen Analysecode aus, der Dateien im Speicher abbildet? Ich bin mir nicht sicher, welches "Argument gegen die Aktivierung von virtuellem Speicher" Sie meinen, aber das würde es praktisch unmöglich machen, mehr als einen Prozess gleichzeitig laufen zu lassen (und wie würde
fork
arbeiten?). Auch hier handelt es sich um eine ziemlich schreckliche Einschränkung, die in der allgemeinen Datenverarbeitung nichts zu suchen hat.0 Stimmen
Wir wollen diese Diskussion im Chat fortsetzen .
0 Stimmen
Weiß jemand, wie man das auch in C# machen kann?