Un moyen pour déterminer un processus de “vrais” l'utilisation de la mémoire, c'est à dire des sales RSS?

Des outils comme 'ps' et 'top rapport des différents types de mémoire usages, tels que la taille de mémoire virtuelle et le Résident de la Taille de l'Ensemble. Cependant, aucune de ces sont les "vrais" l'utilisation de la mémoire:

  • Le code de programme est partagée entre plusieurs instances d'un même programme.
  • Partagée de la bibliothèque de code de programme est partagée entre tous les processus qui utilisent la bibliothèque.
  • Certaines applications fork de processus et de partager de la mémoire avec eux (par exemple via les segments de mémoire partagée).
  • Le système de mémoire virtuelle rend la VM rapport de taille à peu près inutile.
  • RSS est de 0 lorsqu'un processus est échangé, ce qui n'est pas très utile.
  • Etc etc.

J'ai trouvé que le privé sale RSS, tel que rapporté par Linux, est la chose la plus proche à la "vraie" utilisation de la mémoire. Ceci peut être obtenu en additionnant tous Private_Dirty valeurs dans /proc/somepid/smaps.

Cependant, d'autres systèmes d'exploitation fournissent des fonctionnalités similaires? Si non, quelles sont les alternatives? En particulier, je suis intéressé par FreeBSD et mac OS X. les

  • Quel est exactement le "réel de l'utilisation de la mémoire"? Basé sur votre liste, l'idée de l'utilisation de la mémoire pour un processus simple est soit inutile ou arbitraire.
  • J'avais définir le "réel de l'utilisation de la mémoire", comme la quantité de mémoire physique (mais pas de swap) qui serait libérée si je "kill -9' le processus. Je crois que le nombre devrait être quelque part entre les flux RSS et PSS valeurs rapportées pour un processus.
  • est un vieux thread,je suis surpris que le montage linprocfs n'a pas été une partie de la solution suggérée par quelqu'un ici,pour FreeBSD.Est-il une raison spécifique pour la même chose? .J'ai quand même ajouté que la réponse pour le bien de l'achèvement.
InformationsquelleAutor Hongli | 2008-09-22
  1. 41

    Sur OSX le Moniteur d'Activité vous donne une très bonne estimation.

    Mémoire privée est pour vous assurer que la mémoire est uniquement utilisé par votre application. E. g. pile de mémoire et toute la dynamique de la mémoire réservée à l'aide de malloc() et comparables sur les fonctions/méthodes (méthode alloc pour Objective-C) est privé de la mémoire. Si vous fourche, privé de mémoire seront partagés avec votre enfant, mais marqué de copie sur écriture. Cela signifie que tant que la page n'est pas modifiée par le processus (parent ou enfant), il est partagé entre eux. Dès que le processus modifie une page, cette page est copiée avant qu'il soit modifié. Même si cette mémoire est partagée avec une fourchette les enfants (et il peut seulement être partagé avec une fourchette enfants), il est toujours indiqué comme "privé" de la mémoire, parce que dans le pire des cas, chaque page de elle permettra d'obtenir modifiés (tôt ou tard) et puis c'est à nouveau privé de chaque processus à nouveau.

    De mémoire partagée est soit de la mémoire qui est actuellement partagée (les mêmes pages sont visibles dans le virtuel espace de processus de processus différents) ou qui est susceptible de devenir partagé dans le futur (par exemple, mémoire en lecture seule, car il n'y a aucune raison pour ne pas le partage de mémoire en lecture seule). Au moins c'est comment j'ai lu le code source de certains outils de ligne de commande à partir d'Apple. Donc, si vous partager la mémoire entre les processus à l'aide de mmap (ou comparables appel que les cartes de la même mémoire dans plusieurs processus), ce serait de la mémoire partagée. Toutefois, le code exécutable lui-même est également de la mémoire partagée, car si une autre instance de votre application est démarrée il n'ya aucune raison pourquoi il ne peut pas partager le code déjà chargé en mémoire (code exécutable pages sont en lecture seule par défaut, sauf si vous exécutez votre application dans un débogueur). Ainsi, la mémoire partagée est vraiment de la mémoire utilisée par votre application, tout comme le privé, mais il peut en outre être partagé avec un autre processus (ou peut être pas, mais pourquoi ne serait-il pas compter vers votre application si elle est partagée?)

    De la mémoire réelle est la quantité de RAM actuellement "attribué" à votre processus, peu importe si privative ou commune. Cela peut être exactement à la somme des privés et partagés, mais, habituellement, il n'est pas. Votre processus peut disposer de plus de mémoire affectée à elle qu'elle a besoin (ce qui accélère les demandes de plus de mémoire dans le futur), mais c'est pas une perte pour le système. Si un autre processus a besoin de la mémoire et pas de mémoire est disponible, avant le démarrage du système d'échange de fichiers, il faudra que la mémoire supplémentaire loin de vos processus et de l'affecter à un autre processus (ce qui est rapide et indolore de l'opération); à cet effet dans votre prochain appel de malloc peut-être un peu plus lent. La mémoire réelle peut aussi être plus petit que privé et de la mémoire physique; c'est parce que si votre processus de demande de la mémoire du système, il ne recevra de "mémoire virtuelle". Cette mémoire virtuelle est pas lié à une réelle pages de mémoire tant que vous ne l'utilisez pas (donc malloc 10 MO de mémoire, utilisez uniquement un octet, votre processus obtiendrez une seule page, 4096 octets, de la mémoire assignée - le reste n'est attribué que si vous avez réellement jamais besoin d'elle). Plus de la mémoire qui est échangé ne comptent pas dans la mémoire réelle soit (pas sûr à ce sujet), mais le calcul partagés et privés de la mémoire.

    La mémoire virtuelle est la somme de tous les blocs d'adresses qui sont valables dans vos applications à l'espace de processus. Ces adresses peuvent être liés à la mémoire physique (qui est de nouveau privé ou partagé), ou peut-être pas, mais dans ce cas, ils seront liés à la mémoire physique dès que vous utilisez l'adresse. Accéder à la mémoire des adresses en dehors des adresses connues, va provoquer un SIGBUS et votre application crash. Lorsque la mémoire est échangé, l'espace d'adressage virtuel pour cette mémoire reste valable et l'accès à ces adresses causes de la mémoire pour être échangé en retour.

    Conclusion:

    Si votre application ne prend pas explicitement ou implicitement l'utilisation de la mémoire partagée, mémoire privée est la quantité de mémoire de votre application a besoin en raison de la taille de la pile (de taille ou si multithread) et en raison de la fonction malloc() appels que vous avez effectués pour la mémoire dynamique. Vous n'avez pas de soins beaucoup pour le partage ou la mémoire réelle dans ce cas.

    Si votre application utilise la mémoire partagée, et cela inclut une INTERFACE utilisateur graphique, où la mémoire est partagée entre votre application et le WindowServer par exemple, alors vous pourriez avoir un coup d'oeil à mémoire partagée aussi bien. Une très grande mémoire partagée nombre peut signifier que vous avez trop de ressources graphiques chargé en mémoire à l'instant.

    De la mémoire réelle est de peu d'intérêt pour le développement d'applications. Si il est plus grand que la somme de communes et privées, alors cela ne signifie rien d'autre que ce que le système est paresseux à prendre de la mémoire à l'écart de votre processus. Si elle est plus petite, alors votre processus a demandé plus de mémoire que nécessaire, ce qui n'est pas mal non plus, car tant que vous n'utilisez pas la totalité de la mémoire demandée, vous n'êtes pas le "vol" de la mémoire du système. Si elle est beaucoup plus petite que la somme de communes et privées, vous ne pouvez envisager de demander moins de mémoire, si possible, que vous êtes un peu trop demander de la mémoire (encore une fois, ce n'est pas mauvais, mais il me dit que le code n'est pas optimisé pour une faible utilisation de la mémoire et si il est multi plate-forme, d'autres plates-formes peuvent ne pas avoir une telle sophistiqués de gestion de la mémoire, de sorte que vous pouvez préférer alloc de nombreux petits blocs au lieu de quelques grands, par exemple, ou de la mémoire libre beaucoup plus tôt, et ainsi de suite).

    Si vous n'êtes toujours pas satisfait avec toutes ses informations, vous pouvez obtenir encore plus d'informations. Ouvrez un terminal et exécutez:

    sudo vmmap <pid>

    où est l'ID de processus de votre processus. Cela va vous montrer les statistiques pour CHAQUE bloc de mémoire dans votre espace de processus avec le début et la fin de l'adresse. Il vous indiquera également où cette mémoire est venu de (Un fichier mappé? La pile de la mémoire? Malloc ed de mémoire? A __de DONNÉES ou d' __TEXTE de la section de votre exécutable?), comment elle est grande dans la base de connaissances, les droits d'accès et de savoir s'il est privé, partagé ou de copie sur écriture. Si il est mappé à partir d'un fichier, il va même vous donner le chemin d'accès au fichier.

    Si vous souhaitez que seuls les "réels" de l'utilisation de la RAM, l'utilisation

    sudo vmmap -resident <pid>

    Maintenant, il va montrer pour chaque bloc de mémoire la taille du bloc de mémoire est pratiquement et dans quelle mesure il est vraiment actuellement présents dans la mémoire physique.

    À la fin de chaque cliché est aussi un tableau de synthèse avec les sommes de différents types de mémoire. Ce tableau ressemble à ceci pour Firefox en ce moment sur mon système:

    REGION TYPE             [ VIRTUAL/RESIDENT]
===========             [ =======/========]
ATS (font support)      [   33.8M/  2496K]
CG backing stores       [   5588K/  5460K]
CG image                [     20K/    20K]
CG raster data          [    576K/   576K]
CG shared images        [   2572K/  2404K]
Carbon                  [   1516K/  1516K]
CoreGraphics            [      8K/     8K]
IOKit                   [  256.0M/     0K]
MALLOC                  [  256.9M/ 247.2M]
Memory tag=240          [      4K/     4K]
Memory tag=242          [     12K/    12K]
Memory tag=243          [      8K/     8K]
Memory tag=249          [    156K/    76K]
STACK GUARD             [  101.2M/  9908K]
Stack                   [   14.0M/   248K]
VM_ALLOCATE             [   25.9M/  25.6M]
__DATA                  [   6752K/  3808K]
__DATA/__OBJC           [     28K/    28K]
__IMAGE                 [   1240K/   112K]
__IMPORT                [    104K/   104K]
__LINKEDIT              [   30.7M/  3184K]
__OBJC                  [   1388K/  1336K]
__OBJC/__DATA           [     72K/    72K]
__PAGEZERO              [      4K/     0K]
__TEXT                  [  108.6M/  63.5M]
__UNICODE               [    536K/   512K]
mapped file             [  118.8M/  50.8M]
shared memory           [    300K/   276K]
shared pmap             [   6396K/  3120K]

    Ce que nous dit-il? E. g. Firefox binaire et tous de la bibliothèque des charges 108 MO de données ensemble dans leur __les sections de TEXTE, mais actuellement seulement 63 MO de ceux qui sont actuellement résident en mémoire. La prise en charge des polices (ATS) les besoins de 33 MO, mais seulement environ 2,5 MO sont vraiment dans la mémoire. Il utilise un peu plus de 5 MO, CG de la sauvegarde des magasins, CG = Graphiques de Base, ceux qui sont les plus susceptibles contenu de la fenêtre, les boutons, les images et autres données qui est mis en cache pour un dessin rapide. Il a demandé à 256 MO via malloc appels et actuellement 247 MO sont vraiment dans mappés à des pages de mémoire. Il dispose de 14 MO d'espace réservé pour les piles, mais seulement 248 KO d'espace de pile est vraiment en cours d'utilisation dès maintenant.

    vmmap a aussi un bon résumé au-dessus de la table

    ReadOnly portion of Libraries: Total=139.3M resident=66.6M(48%) swapped_out_or_unallocated=72.7M(52%)
Writable regions: Total=595.4M written=201.8M(34%) resident=283.1M(48%) swapped_out=0K(0%) unallocated=312.3M(52%)

    Et cela montre un aspect intéressant de l'OS X: Pour mémoire en lecture seule, il ne joue aucun rôle, s'il est échangé ou tout simplement non alloué; il n'est qu'résident et non résident. Pour l'écriture de la mémoire cela fait une différence (dans mon cas, 52% de toutes les demandes de mémoire n'a jamais été utilisé et est non alloué, 0% de mémoire a été transférée sur le disque)

    InformationsquelleAutor Mecki
  2. 9

    Sur Linux, vous pouvez le PSS (proportionnelle de la taille de l'ensemble des numéros du répertoire /proc/self/smaps. Une cartographie du PSS est son RSS divisé par le nombre de processus qui sont à l'aide de cette cartographie.

    • Est-il une commande sur Linux (Ubuntu 18.04) pour renvoyer le PSS d'un processus?
    InformationsquelleAutor Justin L.
  3. 6

    Haut sait comment faire cela. Il montre VIRT, RES et SHR par défaut sur Linux Debian. VIRT = SWAP + RES. RES = CODE + DONNÉES. SHR est la mémoire qui peut être partagé avec un autre processus (bibliothèque partagée ou autre mémoire.)

    Aussi, "sale" de la mémoire est simplement RES de la mémoire qui a été utilisée, et/ou n'a pas été échangés.

    Il peut être difficile de le dire, mais la meilleure façon de le comprendre est de regarder d'un système qui n'est pas de permutation. Ensuite, RES - SHR est le processus exclusif de la mémoire. Cependant, ce n'est pas une bonne façon de le regarder, parce que vous ne savez pas que la mémoire de SHR est utilisé par un autre processus. Il peut représenter non écrite objet partagé les pages qui ne sont utilisées par le processus.

    • Je ne pense pas que c'est correct. Envisagez de pastie.org/277766 Cette cartes de 300 MO dans l'espace d'adressage, mais le dernier octet est écrit à. Le réel de l'utilisation de la mémoire pour que le bloc de 4 KO (taille d'une page). Le processus réel d'utilisation de la mémoire ne doit être plusieurs KO.
    • La mémoire inutilisée dans votre exemple, encore dans la VIRT total. Et le RES total de refléter la mémoire inutilisée (c'est à dire, ne pas le montrer.) Au moins, c'est theway il semble fonctionner sur Debian x86.
    • Je suis d'accord avec vous. RES-SHR sera un bon moyen pour évaluer les processus de l'utilisation de la mémoire pour la plupart des processus. Généralement la mémoire des fuites se produisent dans la mémoire privée et c'est ce que vous allez étudier. Si l'on veut connaître la pleine utilisation de la mémoire, il ne faut pas résumer les processus, mais aller en haut/htop dans l'ensemble.
    InformationsquelleAutor Chris
  4. 5

    Vous ne pouvez vraiment pas.

    Je veux dire, de mémoire partagée entre les processus... allez-vous de les compter, ou pas. Si vous ne comptez pas, vous êtes mal; la somme de tous les processus' utilisation de la mémoire ne va pas être le total de l'utilisation de la mémoire. Si vous comptez, vous allez compter deux fois la somme ne sera pas correcte.

    Moi, je suis heureux avec les flux RSS. Et en sachant que vous ne pouvez pas vraiment compter sur elle complètement...

    InformationsquelleAutor alex
  5. 5

    Vous pouvez vous procurer private sale et privé propre flux RSS à partir de /proc/pid/smaps

    InformationsquelleAutor abc
  6. 3

    Prendre un coup d'oeil à smem. Il vous donnera PSS informations

    http://www.selenic.com/smem/

    InformationsquelleAutor gheese
  7. 2

    Utiliser le mincore(2) de l'appel système. Citant la page de man:

    DESCRIPTION
     The mincore() system call determines whether each of the pages in the
     region beginning at addr and continuing for len bytes is resident.  The
     status is returned in the vec array, one character per page.  Each
     character is either 0 if the page is not resident, or a combination of
     the following flags (defined in <sys/mman.h>):
    InformationsquelleAutor Edward Tomasz Napierala
  8. 2

    Retravaillé ce sera beaucoup plus propre, pour démontrer le bien meilleures pratiques en bash, et en particulier à l'utilisation awk au lieu de bc.

    find /proc/ -maxdepth 1 -name '[0-9]*' -print0 | while read -r -d $'
    find /proc/ -maxdepth 1 -name '[0-9]*' -print0 | while read -r -d $'\0' pidpath; do
[ -f "${pidpath}/smaps" ] || continue
awk '!/^Private_Dirty:/{next;}
$3=="kB" {pd += $2 * (1024^1); next}
$3=="mB" {pd += $2 * (1024^2); next}
$3=="gB" {pd += $2 * (1024^3); next}
$3=="tB" {pd += $2 * (1024^4); next}
$3=="pB" {pd += $2 * (1024^5); next}
{print "ERROR!!  "$0 >"/dev/stderr"; exit(1)}
END {printf("%10d: %d\n", '"${pidpath##*/}"', pd)}' "${pidpath}/smaps" || break
done
    '     pidpath; do
  [ -f "${pidpath}/smaps" ] || continue
  awk '!/^Private_Dirty:/{next;}
       $3=="kB" {pd += $2 * (1024^1); next}
       $3=="mB" {pd += $2 * (1024^2); next}
       $3=="gB" {pd += $2 * (1024^3); next}
       $3=="tB" {pd += $2 * (1024^4); next}
       $3=="pB" {pd += $2 * (1024^5); next}
       {print "ERROR!!  "$0 >"/dev/stderr"; exit(1)}
       END {printf("%10d: %d\n", '"${pidpath##*/}"', pd)}' "${pidpath}/smaps" || break
done

    Sur un pratique petit récipient sur ma machine, avec | sort -n -k 2 pour trier la sortie, cela ressemble à:

            56: 106496
         1: 147456
        55: 155648
    InformationsquelleAutor BMDan
  9. 1

    Pour une question que mentionné Freebsd, sans surprise écrit encore :

    Si vous voulez un linux style /proc/PROCESSID/sortie de l'état, procédez de la façon suivante : 

    mount -t linprocfs none /proc
cat /proc/PROCESSID/status

    Atleast dans FreeBSD 7.0, le montage n'a pas été fait par défaut ( 7.0 est beaucoup plus ancienne version,mais pour quelque chose de cette base,la réponse a été caché dans une liste de diffusion!)

    InformationsquelleAutor Arvind
  10. 1

    Le vérifier, c'est le code source de gnome-system-monitor, il pense à la mémoire "vraiment utilisé" par un processus de somme(info->mem) de X de la Mémoire du Serveur(info->memxserver) et d'Écriture de la Mémoire(info->memwritable), le "Écriture de la Mémoire" est les blocs de mémoire qui sont marqués comme "Private_Dirty" dans /proc/PID/smaps fichier.

    Autres que le système linux, peuvent être différentes en fonction de gnome-system-monitor code.

    static void
get_process_memory_writable (ProcInfo *info)
{
    glibtop_proc_map buf;
    glibtop_map_entry *maps;

    maps = glibtop_get_proc_map(&buf, info->pid);

    gulong memwritable = 0;
    const unsigned number = buf.number;

    for (unsigned i = 0; i < number; ++i) {
#ifdef __linux__
        memwritable += maps[i].private_dirty;
#else
        if (maps[i].perm & GLIBTOP_MAP_PERM_WRITE)
            memwritable += maps[i].size;
#endif
    }

    info->memwritable = memwritable;

    g_free(maps);
}

static void
get_process_memory_info (ProcInfo *info)
{
    glibtop_proc_mem procmem;
    WnckResourceUsage xresources;

    wnck_pid_read_resource_usage (gdk_screen_get_display (gdk_screen_get_default ()),
                                  info->pid,
                                  &xresources);

    glibtop_get_proc_mem(&procmem, info->pid);

    info->vmsize    = procmem.vsize;
    info->memres    = procmem.resident;
    info->memshared = procmem.share;

    info->memxserver = xresources.total_bytes_estimate;

    get_process_memory_writable(info);

    //fake the smart memory column if writable is not available
    info->mem = info->memxserver + (info->memwritable ? info->memwritable : info->memres);
}
    InformationsquelleAutor workplaylifecycle