Linux
Sous Linux, ces informations sont disponibles dans le système de fichiers /proc. Je ne suis pas un grand fan du format de fichier texte utilisé, car chaque distribution Linux semble personnaliser au moins un fichier important. Un rapide coup d'oeil à la source de 'ps' révèle le désordre.
Mais voici où trouver les informations que vous cherchez :
/proc/meminfo contient la majorité des informations relatives au système que vous recherchez. Voici à quoi cela ressemble sur mon système ; je pense que vous êtes intéressé par MemTotal , MemFree , SwapTotal y 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
Pour l'utilisation du CPU, il faut faire un peu de travail. Linux met à disposition l'utilisation globale du CPU depuis le démarrage du système ; ce n'est probablement pas ce qui vous intéresse. Si vous voulez savoir quelle a été l'utilisation du CPU au cours de la dernière seconde, ou des 10 dernières secondes, vous devez interroger l'information et la calculer vous-même.
Les informations sont disponibles dans /proc/stat qui est très bien documenté à l'adresse http://www.linuxhowtos.org/System/procstat.htm Voici à quoi ça ressemble sur ma boîte à 4 fils :
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
Tout d'abord, vous devez déterminer combien de CPU (ou processeurs, ou cœurs de traitement) sont disponibles dans le système. Pour ce faire, comptez le nombre d'entrées 'cpuN', où N commence à 0 et s'incrémente. Ne comptez pas la ligne 'cpu', qui est une combinaison des lignes 'cpuN'. Dans mon exemple, vous pouvez voir cpu0 à cpu3, pour un total de 4 processeurs. A partir de maintenant, vous pouvez ignorer les cpu0..cpu3, et vous concentrer uniquement sur la ligne 'cpu'.
Ensuite, vous devez savoir que le quatrième chiffre de ces lignes est une mesure du temps d'inactivité, et donc le quatrième chiffre de la ligne "cpu" est le temps d'inactivité total pour tous les processeurs depuis le démarrage. Ce temps est mesuré en "jiffies" Linux, qui sont de 1/100 de seconde chacun.
Mais vous ne vous souciez pas du temps d'inactivité total ; vous vous souciez du temps d'inactivité dans une période donnée, par exemple, la dernière seconde. Pour calculer cela, vous devez lire ce fichier deux fois, à une seconde d'intervalle, puis vous pouvez faire une comparaison de la quatrième valeur de la ligne. Par exemple, si vous prenez un échantillon et obtenez :
cpu 2330047 0 2365006 1063853632 9035 9463 96114 0
Puis, une seconde plus tard, vous obtenez cet échantillon :
cpu 2330047 0 2365007 1063854028 9035 9463 96114 0
Soustrayez les deux nombres, et vous obtenez une différence de 396, ce qui signifie que votre CPU a été inactif pendant 3,96 secondes sur les 1,00 dernières secondes. L'astuce, bien sûr, est que vous devez diviser par le nombre de processeurs. 3,96 / 4 = 0,99, et voilà votre pourcentage d'inactivité : 99% d'inactivité et 1% d'occupation.
Dans mon code, j'ai un tampon circulaire de 360 entrées, et je lis ce fichier toutes les secondes. Cela me permet de calculer rapidement l'utilisation du CPU pour 1 seconde, 10 secondes, etc., jusqu'à 1 heure.
Pour les informations spécifiques au processus, vous devez chercher dans /proc/pid si vous ne vous souciez pas de votre pid, vous pouvez regarder dans /proc/self.
Le CPU utilisé par votre processus est disponible dans /proc/self/stat . Il s'agit d'un fichier d'apparence étrange composé d'une seule ligne ; par exemple :
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
Les données importantes ici sont les 13ème et 14ème jetons (0 et 770 ici). Le 13e jeton est le nombre de jiffies que le processus a exécuté en mode utilisateur, et le 14e est le nombre de jiffies que le processus a exécuté en mode noyau. Additionnez les deux et vous obtenez son utilisation totale du CPU.
Encore une fois, vous devrez échantillonner ce fichier périodiquement, et calculer la différence, afin de déterminer l'utilisation du CPU du processus au fil du temps.
Editar: N'oubliez pas que lorsque vous calculez l'utilisation du CPU de votre processus, vous devez prendre en compte 1) le nombre de threads de votre processus, et 2) le nombre de processeurs du système. Par exemple, si votre processus à un seul thread n'utilise que 25 % du CPU, cela peut être bon ou mauvais. Bon sur un système à un seul processeur, mais mauvais sur un système à 4 processeurs ; cela signifie que votre processus fonctionne en permanence et utilise 100 % des cycles du CPU dont il dispose.
Pour les informations de mémoire spécifiques au processus, vous devez regarder /proc/self/status, qui ressemble à ceci :
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
Les entrées qui commencent par "Vm" sont les plus intéressantes :
-
VmPeak est l'espace mémoire virtuel maximum utilisé par le processus, en kB (1024 octets).
-
VmSize est l'espace mémoire virtuel actuel utilisé par le processus, en kB. Dans mon exemple, c'est assez grand : 651,352 kB, ou environ 636 mégaoctets.
-
VmRss est la quantité de mémoire qui a été mappée dans l'espace d'adressage du processus, ou la taille de son ensemble résident. Celle-ci est sensiblement plus petite (420 296 kB, soit environ 410 mégaoctets). La différence : mon programme a mappé 636 MB via mmap(), mais n'a accédé qu'à 410 MB de cette mémoire, et donc seulement 410 MB de pages lui ont été assignées.
Le seul point sur lequel je ne suis pas sûr est Espace de permutation actuellement utilisé par mon processus . Je ne sais pas si cela est disponible.
16 votes
"La mémoire virtuelle totale disponible" n'a aucun sens sur les systèmes d'exploitation modernes.
74 votes
Pourquoi cela n'a-t-il pas de sens ? Cela invalide-t-il la réponse donnée ici ? stackoverflow.com/questions/3296211/ ... s'il vous plaît, ne laissez pas de cliffhangers lorsque vous commentez, ce n'est pas une série télévisée.
3 votes
@MindaugasBernatavicius : La question liée concerne la "mémoire physique totale", qui est un fait matériel connu du système d'exploitation. Vous obtenez le total en additionnant les tailles de tous les modules de mémoire. La "mémoire virtuelle totale disponible", d'autre part, qu'est-ce que cela signifie ? Est-ce l'espace d'adressage virtuel combiné de tous les processus qui pourraient théoriquement être créés ? Ce nombre serait d'environ 2^80 octets, donc certainement sans signification.
4 votes
@MSalters - merci de vous engager. Je pense que demander ce que le PO avait à l'esprit est beaucoup plus gentil et sain que de déclarer que quelque chose n'a pas de sens (sans explication). Si vous remarquez, les réponses supposent également une position particulière à cet égard : Mémoire virtuelle = RAM + SWAP (ou PAGEFILE) - ce qui est une hypothèse raisonnable. Nous savons donc qu'elle n'est pas dénuée de sens, puisqu'il existe une interprétation particulière de ce terme (qui n'est peut-être pas la plus techniquement correcte, un langage familier) qui a un sens.
5 votes
@MindaugasBernatavicius : Cela ignore les fichiers mappés en mémoire et le code qui n'est pas paginé. Linux a des allocations de mémoire non engagées (non soutenues par de la RAM ou du swap) et Windows a des piles non engagées.