bonjour a tous,
j ai fait une petite recherche sur le net pour essayer
de comprendre la difference entre SIZE ET RES...
j ai vaguement compris donc si quelqu un avait la
gentillesse de me l expliquer ;)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Pascal Bourguignon
nicolas writes:
bonjour a tous, j ai fait une petite recherche sur le net pour essayer de comprendre la difference entre SIZE ET RES... j ai vaguement compris donc si quelqu un avait la gentillesse de me l expliquer ;)
As tu essayé man top ?
Je ne trouve pas de colonne SIZE (dans top: procps version 3.1.6), mais RES, c'est la taille de RAM utilisée par le programme et ses données. Note qu'une partie de RES peut être partagée (SHR) avec d'autres processus. Il faudrait alors diviser cette partie par le nombre de processus qui la partage...
o: VIRT -- Virtual Image (kb) The total amount of virtual memory used by the task. It includes all code, data and shared libraries plus pages that have been swapped out.
VIRT = SWAP + RES.
p: SWAP -- Swapped size (kb) The swapped out portion of a task's total virtual memory image.
q: RES -- Resident size (kb) The non-swapped physical memory a task has used.
RES = CODE + DATA.
r: CODE -- Code size (kb) The amount of physical memory devoted to executable code, also known as the 'text resident set' size or TRS.
s: DATA -- Data+Stack size (kb) The amount of physical memory devoted to other than executable code, also known as the 'data resident set' size or DRS.
t: SHR -- Shared Mem size (kb) The amount of shared memory used by a task. It simply reflects memory that could be potentially shared with other processes.
Our enemies are innovative and resourceful, and so are we. They never stop thinking about new ways to harm our country and our people, and neither do we.
nicolas <nico@rominet.home> writes:
bonjour a tous,
j ai fait une petite recherche sur le net pour essayer
de comprendre la difference entre SIZE ET RES...
j ai vaguement compris donc si quelqu un avait la
gentillesse de me l expliquer ;)
As tu essayé man top ?
Je ne trouve pas de colonne SIZE (dans top: procps version 3.1.6),
mais RES, c'est la taille de RAM utilisée par le programme et ses
données. Note qu'une partie de RES peut être partagée (SHR) avec
d'autres processus. Il faudrait alors diviser cette partie par le
nombre de processus qui la partage...
o: VIRT -- Virtual Image (kb)
The total amount of virtual memory used by the task. It includes all
code, data and shared libraries plus pages that have been swapped out.
VIRT = SWAP + RES.
p: SWAP -- Swapped size (kb)
The swapped out portion of a task's total virtual memory image.
q: RES -- Resident size (kb)
The non-swapped physical memory a task has used.
RES = CODE + DATA.
r: CODE -- Code size (kb)
The amount of physical memory devoted to executable code, also known
as the 'text resident set' size or TRS.
s: DATA -- Data+Stack size (kb)
The amount of physical memory devoted to other than executable code,
also known as the 'data resident set' size or DRS.
t: SHR -- Shared Mem size (kb)
The amount of shared memory used by a task. It simply reflects memory
that could be potentially shared with other processes.
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we.
bonjour a tous, j ai fait une petite recherche sur le net pour essayer de comprendre la difference entre SIZE ET RES... j ai vaguement compris donc si quelqu un avait la gentillesse de me l expliquer ;)
As tu essayé man top ?
Je ne trouve pas de colonne SIZE (dans top: procps version 3.1.6), mais RES, c'est la taille de RAM utilisée par le programme et ses données. Note qu'une partie de RES peut être partagée (SHR) avec d'autres processus. Il faudrait alors diviser cette partie par le nombre de processus qui la partage...
o: VIRT -- Virtual Image (kb) The total amount of virtual memory used by the task. It includes all code, data and shared libraries plus pages that have been swapped out.
VIRT = SWAP + RES.
p: SWAP -- Swapped size (kb) The swapped out portion of a task's total virtual memory image.
q: RES -- Resident size (kb) The non-swapped physical memory a task has used.
RES = CODE + DATA.
r: CODE -- Code size (kb) The amount of physical memory devoted to executable code, also known as the 'text resident set' size or TRS.
s: DATA -- Data+Stack size (kb) The amount of physical memory devoted to other than executable code, also known as the 'data resident set' size or DRS.
t: SHR -- Shared Mem size (kb) The amount of shared memory used by a task. It simply reflects memory that could be potentially shared with other processes.
Our enemies are innovative and resourceful, and so are we. They never stop thinking about new ways to harm our country and our people, and neither do we.
Jérémy JUST
On Sat, 18 Sep 2004 19:11:07 +0200 nicolas wrote:
j ai fait une petite recherche sur le net pour essayer de comprendre la difference entre SIZE ET RES... j ai vaguement compris donc si quelqu un avait la gentillesse de me l expliquer ;)
RES est la mémoire résidente (ie ce qui est en RAM+swap) alors que SIZE contient aussi l'ensemble des données mappées par le processus (avec mmap, par exemple) et qui sont en fait sur le disque.
Condensé d'un thread lu sur http://www.mail-archive.com/ :
<<<<< What, exactly, is RES? `man top` describes it as this: "RES is the current amount of resident memory", but does that mean RES is included in SIZE? Or does that mean that RES should be counted in addition to SIZE?
RES the amount of SIZE that it currently in core, and thus should never exceed SIZE (I don't see any processes on my system that do at least).
OK. To clarify, you mean core kernel memory here? If so, how is that significant? Why should I care? In other words, why would I ever want to know that?
No, it's not in kernel space. "Core" just refers to RAM: the term is held over from the days when main memory was constructed out of little magnetic cores in a wire matrix. If your system starts swapping heavily, that will often be the clue that tells you why. Just one example. Core meaning physical memory; user memory in this case. Processes can lock kernel memory, but there's no easy way of listing that (it's usually a small amount held in pipe or socket buffers and is short-lived). The name "core" came from when memory bits were ferrite rings magnetized by wires running through them. Processes can lock kernel memory, but there's no easy way of listing that (it's usually a small amount held in pipe or socket buffers and is short-lived). The name "core" came from when memory bits were ferrite rings magnetized by wires running through them. See http://www.columbia.edu/acis/history/core.html.
OK. And how does core, or user memory differ from SIZE memory then? If X = SIZE - RES, where is X stored?
You don't need to store it, since you know SIZE and RES :) X is any memory mapped into process space that is not in physical memory at the moment; it could be dirty or private pages swapped to disk, or program code that can be pulled from the binary on the filesystem if necessary, or malloced memory that hasn't been written to yet.
-- Jérémy JUST
On Sat, 18 Sep 2004 19:11:07 +0200
nicolas <nico@rominet.home> wrote:
j ai fait une petite recherche sur le net pour essayer
de comprendre la difference entre SIZE ET RES...
j ai vaguement compris donc si quelqu un avait la
gentillesse de me l expliquer ;)
RES est la mémoire résidente (ie ce qui est en RAM+swap) alors que
SIZE contient aussi l'ensemble des données mappées par le processus
(avec mmap, par exemple) et qui sont en fait sur le disque.
Condensé d'un thread lu sur http://www.mail-archive.com/ :
<<<<<
What, exactly, is RES? `man top` describes it as this:
"RES is the current amount of resident memory", but does that mean RES
is included in SIZE? Or does that mean that RES should be counted in
addition to SIZE?
RES the amount of SIZE that it currently in core, and thus should never
exceed SIZE (I don't see any processes on my system that do at least).
OK. To clarify, you mean core kernel memory here? If so, how is that
significant? Why should I care? In other words, why would I ever want to
know that?
No, it's not in kernel space. "Core" just refers to RAM: the term is
held over from the days when main memory was constructed out of little
magnetic cores in a wire matrix. If your system starts swapping heavily,
that will often be the clue that tells you why. Just one example. Core
meaning physical memory; user memory in this case. Processes can lock
kernel memory, but there's no easy way of listing that (it's usually a
small amount held in pipe or socket buffers and is short-lived). The
name "core" came from when memory bits were ferrite rings magnetized by
wires running through them. Processes can lock kernel memory, but
there's no easy way of listing that (it's usually a small amount held in
pipe or socket buffers and is short-lived). The name "core" came from
when memory bits were ferrite rings magnetized by wires running through
them. See http://www.columbia.edu/acis/history/core.html.
OK. And how does core, or user memory differ from SIZE memory
then? If X = SIZE - RES, where is X stored?
You don't need to store it, since you know SIZE and RES :) X is
any memory mapped into process space that is not in physical memory at
the moment; it could be dirty or private pages swapped to disk, or
program code that can be pulled from the binary on the filesystem if
necessary, or malloced memory that hasn't been written to yet.
j ai fait une petite recherche sur le net pour essayer de comprendre la difference entre SIZE ET RES... j ai vaguement compris donc si quelqu un avait la gentillesse de me l expliquer ;)
RES est la mémoire résidente (ie ce qui est en RAM+swap) alors que SIZE contient aussi l'ensemble des données mappées par le processus (avec mmap, par exemple) et qui sont en fait sur le disque.
Condensé d'un thread lu sur http://www.mail-archive.com/ :
<<<<< What, exactly, is RES? `man top` describes it as this: "RES is the current amount of resident memory", but does that mean RES is included in SIZE? Or does that mean that RES should be counted in addition to SIZE?
RES the amount of SIZE that it currently in core, and thus should never exceed SIZE (I don't see any processes on my system that do at least).
OK. To clarify, you mean core kernel memory here? If so, how is that significant? Why should I care? In other words, why would I ever want to know that?
No, it's not in kernel space. "Core" just refers to RAM: the term is held over from the days when main memory was constructed out of little magnetic cores in a wire matrix. If your system starts swapping heavily, that will often be the clue that tells you why. Just one example. Core meaning physical memory; user memory in this case. Processes can lock kernel memory, but there's no easy way of listing that (it's usually a small amount held in pipe or socket buffers and is short-lived). The name "core" came from when memory bits were ferrite rings magnetized by wires running through them. Processes can lock kernel memory, but there's no easy way of listing that (it's usually a small amount held in pipe or socket buffers and is short-lived). The name "core" came from when memory bits were ferrite rings magnetized by wires running through them. See http://www.columbia.edu/acis/history/core.html.
OK. And how does core, or user memory differ from SIZE memory then? If X = SIZE - RES, where is X stored?
You don't need to store it, since you know SIZE and RES :) X is any memory mapped into process space that is not in physical memory at the moment; it could be dirty or private pages swapped to disk, or program code that can be pulled from the binary on the filesystem if necessary, or malloced memory that hasn't been written to yet.
-- Jérémy JUST
nicolas
Jérémy JUST wrote:
On Sat, 18 Sep 2004 19:11:07 +0200 nicolas wrote:
j ai fait une petite recherche sur le net pour essayer de comprendre la difference entre SIZE ET RES... j ai vaguement compris donc si quelqu un avait la gentillesse de me l expliquer ;)
RES est la mémoire résidente (ie ce qui est en RAM+swap) alors que SIZE contient aussi l'ensemble des données mappées par le processus (avec mmap, par exemple) et qui sont en fait sur le disque.
Condensé d'un thread lu sur http://www.mail-archive.com/ :
<<<<< What, exactly, is RES? `man top` describes it as this: "RES is the current amount of resident memory", but does that mean RES is included in SIZE? Or does that mean that RES should be counted in addition to SIZE?
RES the amount of SIZE that it currently in core, and thus should never exceed SIZE (I don't see any processes on my system that do at least).
OK. To clarify, you mean core kernel memory here? If so, how is that significant? Why should I care? In other words, why would I ever want to know that?
No, it's not in kernel space. "Core" just refers to RAM: the term is held over from the days when main memory was constructed out of little magnetic cores in a wire matrix. If your system starts swapping heavily, that will often be the clue that tells you why. Just one example. Core meaning physical memory; user memory in this case. Processes can lock kernel memory, but there's no easy way of listing that (it's usually a small amount held in pipe or socket buffers and is short-lived). The name "core" came from when memory bits were ferrite rings magnetized by wires running through them. Processes can lock kernel memory, but there's no easy way of listing that (it's usually a small amount held in pipe or socket buffers and is short-lived). The name "core" came from when memory bits were ferrite rings magnetized by wires running through them. See http://www.columbia.edu/acis/history/core.html.
OK. And how does core, or user memory differ from SIZE memory then? If X = SIZE - RES, where is X stored?
You don't need to store it, since you know SIZE and RES :) X is any memory mapped into process space that is not in physical memory at the moment; it could be dirty or private pages swapped to disk, or program code that can be pulled from the binary on the filesystem if necessary, or malloced memory that hasn't been written to yet.
merci bcp pour vos reponses c'est tt a fait ce que je recherchais.
merci encore
Jérémy JUST wrote:
On Sat, 18 Sep 2004 19:11:07 +0200
nicolas <nico@rominet.home> wrote:
j ai fait une petite recherche sur le net pour essayer
de comprendre la difference entre SIZE ET RES...
j ai vaguement compris donc si quelqu un avait la
gentillesse de me l expliquer ;)
RES est la mémoire résidente (ie ce qui est en RAM+swap) alors que
SIZE contient aussi l'ensemble des données mappées par le processus
(avec mmap, par exemple) et qui sont en fait sur le disque.
Condensé d'un thread lu sur http://www.mail-archive.com/ :
<<<<<
What, exactly, is RES? `man top` describes it as this:
"RES is the current amount of resident memory", but does that mean RES
is included in SIZE? Or does that mean that RES should be counted in
addition to SIZE?
RES the amount of SIZE that it currently in core, and thus should never
exceed SIZE (I don't see any processes on my system that do at least).
OK. To clarify, you mean core kernel memory here? If so, how is that
significant? Why should I care? In other words, why would I ever want to
know that?
No, it's not in kernel space. "Core" just refers to RAM: the term is
held over from the days when main memory was constructed out of little
magnetic cores in a wire matrix. If your system starts swapping heavily,
that will often be the clue that tells you why. Just one example. Core
meaning physical memory; user memory in this case. Processes can lock
kernel memory, but there's no easy way of listing that (it's usually a
small amount held in pipe or socket buffers and is short-lived). The
name "core" came from when memory bits were ferrite rings magnetized by
wires running through them. Processes can lock kernel memory, but
there's no easy way of listing that (it's usually a small amount held in
pipe or socket buffers and is short-lived). The name "core" came from
when memory bits were ferrite rings magnetized by wires running through
them. See http://www.columbia.edu/acis/history/core.html.
OK. And how does core, or user memory differ from SIZE memory
then? If X = SIZE - RES, where is X stored?
You don't need to store it, since you know SIZE and RES :) X is
any memory mapped into process space that is not in physical memory at
the moment; it could be dirty or private pages swapped to disk, or
program code that can be pulled from the binary on the filesystem if
necessary, or malloced memory that hasn't been written to yet.
merci bcp pour vos reponses c'est tt a fait ce que je recherchais.
j ai fait une petite recherche sur le net pour essayer de comprendre la difference entre SIZE ET RES... j ai vaguement compris donc si quelqu un avait la gentillesse de me l expliquer ;)
RES est la mémoire résidente (ie ce qui est en RAM+swap) alors que SIZE contient aussi l'ensemble des données mappées par le processus (avec mmap, par exemple) et qui sont en fait sur le disque.
Condensé d'un thread lu sur http://www.mail-archive.com/ :
<<<<< What, exactly, is RES? `man top` describes it as this: "RES is the current amount of resident memory", but does that mean RES is included in SIZE? Or does that mean that RES should be counted in addition to SIZE?
RES the amount of SIZE that it currently in core, and thus should never exceed SIZE (I don't see any processes on my system that do at least).
OK. To clarify, you mean core kernel memory here? If so, how is that significant? Why should I care? In other words, why would I ever want to know that?
No, it's not in kernel space. "Core" just refers to RAM: the term is held over from the days when main memory was constructed out of little magnetic cores in a wire matrix. If your system starts swapping heavily, that will often be the clue that tells you why. Just one example. Core meaning physical memory; user memory in this case. Processes can lock kernel memory, but there's no easy way of listing that (it's usually a small amount held in pipe or socket buffers and is short-lived). The name "core" came from when memory bits were ferrite rings magnetized by wires running through them. Processes can lock kernel memory, but there's no easy way of listing that (it's usually a small amount held in pipe or socket buffers and is short-lived). The name "core" came from when memory bits were ferrite rings magnetized by wires running through them. See http://www.columbia.edu/acis/history/core.html.
OK. And how does core, or user memory differ from SIZE memory then? If X = SIZE - RES, where is X stored?
You don't need to store it, since you know SIZE and RES :) X is any memory mapped into process space that is not in physical memory at the moment; it could be dirty or private pages swapped to disk, or program code that can be pulled from the binary on the filesystem if necessary, or malloced memory that hasn't been written to yet.
merci bcp pour vos reponses c'est tt a fait ce que je recherchais.
