* [9fans] output of ps(1) memory usage
@ 2003-02-21 0:51 okamoto
2003-02-21 1:10 ` Russ Cox
2003-02-21 2:23 ` David Presotto
0 siblings, 2 replies; 18+ messages in thread
From: okamoto @ 2003-02-21 0:51 UTC (permalink / raw)
To: 9fans
Is the output of ps(1) on the amount of used memory will not
shrink natural? If so, what is the reason?
I'm seeing this for threaded programs such as ame and marsv.
Kenji
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [9fans] output of ps(1) memory usage
2003-02-21 0:51 [9fans] output of ps(1) memory usage okamoto
@ 2003-02-21 1:10 ` Russ Cox
2003-02-21 1:18 ` rob pike, esq.
2003-02-21 2:23 ` David Presotto
1 sibling, 1 reply; 18+ messages in thread
From: Russ Cox @ 2003-02-21 1:10 UTC (permalink / raw)
To: 9fans
> Is the output of ps(1) on the amount of used memory will not
> shrink natural?
I think you're asking whether the amount of memory
used by a process ever shrinks. The answer to that is no.
> If so, what is the reason?
Almost all programs allocate memory by increasing
the size of the data segment (see brk(2)). It's possible
to reduce the size, but first you have to get all the good
data out of the area you're about to give back. The standard
malloc/free interface does not attempt to give anything back.
It probably should, but it's not much of an issue for us --
once we clear out our memory leaks programs tend to reach
a steady size and then not grow further.
> I'm seeing this for threaded programs such as ame and marsv.
Leak(1) will check a running program for memory leaks,
in case you are concerned about that.
Russ
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [9fans] output of ps(1) memory usage
2003-02-21 1:10 ` Russ Cox
@ 2003-02-21 1:18 ` rob pike, esq.
0 siblings, 0 replies; 18+ messages in thread
From: rob pike, esq. @ 2003-02-21 1:18 UTC (permalink / raw)
To: 9fans
Also, in case it's not obvious, when you see something like
%% ps | grep rio
rob 13 0:04 0:46 1280K Rendez rio
rob 133 0:00 0:00 1280K Pread rio
rob 134 0:00 0:00 1280K Pread rio
rob 135 0:00 0:00 1280K Rendez rio
rob 136 0:00 0:00 1280K Pread rio
rob 137 0:01 0:01 1280K Pread rio
rob 138 0:00 0:00 1280K Await rio
rob 153 0:00 0:00 1280K Await rio
rob 193 0:00 0:00 1280K Await rio
rob 863 0:00 0:00 1280K Await rio
rob 1721 0:00 0:00 1280K Await rio
rob 1828 0:00 0:00 1280K Await rio
rob 2191 0:00 0:00 1280K Await rio
%%
that 1280K is almost entirely a shared single copy of
the memory. The only part not in common is a single
page (most likely) of per-process stack.
In other words, don't add up the memory column of
ps to decide how much memory is in use.
-rob
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [9fans] output of ps(1) memory usage
2003-02-21 0:51 [9fans] output of ps(1) memory usage okamoto
2003-02-21 1:10 ` Russ Cox
@ 2003-02-21 2:23 ` David Presotto
1 sibling, 0 replies; 18+ messages in thread
From: David Presotto @ 2003-02-21 2:23 UTC (permalink / raw)
To: 9fans
[-- Attachment #1: Type: text/plain, Size: 115 bytes --]
cat /dev/swap to see how much memory is really inuse.
The first number is the number of pages used by user
procs.
[-- Attachment #2: Type: message/rfc822, Size: 1445 bytes --]
From: okamoto@granite.cias.osakafu-u.ac.jp
To: 9fans@cse.psu.edu
Subject: [9fans] output of ps(1) memory usage
Date: Fri, 21 Feb 2003 09:51:14 +0900
Message-ID: <fb1108845028587edcc453aa0ff26a26@granite.cias.osakafu-u.ac.jp>
Is the output of ps(1) on the amount of used memory will not
shrink natural? If so, what is the reason?
I'm seeing this for threaded programs such as ame and marsv.
Kenji
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [9fans] output of ps(1) memory usage
@ 2003-02-21 1:55 okamoto
0 siblings, 0 replies; 18+ messages in thread
From: okamoto @ 2003-02-21 1:55 UTC (permalink / raw)
To: 9fans
I'm now fighting against possible memory leak of marsv.
>> Is the output of ps(1) on the amount of used memory will not
>> shrink natural?
>
> I think you're asking whether the amount of memory
> used by a process ever shrinks. The answer to that is no.
I should have been more clear. The background of my question
was that I first showed a image(206554 bytes), and the ps(1)
results are:
okamoto 478 0:07 0:00 35988K Rendez marsv
okamoto 479 0:00 0:00 35988K Pread marsv
okamoto 480 0:00 0:00 35988K Pread marsv
then, cleared it, and read again a smaller image(21698 bytes),
and the results are:
okamoto 478 0:15 0:00 35988K Rendez marsv
okamoto 479 0:00 0:00 35988K Pread marsv
okamoto 480 0:00 0:00 35988K Pread marsv
This was the reason why I asked the previous question.
Kenji
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [9fans] output of ps(1) memory usage
@ 2003-02-21 2:06 okamoto
2003-02-21 2:08 ` Russ Cox
0 siblings, 1 reply; 18+ messages in thread
From: okamoto @ 2003-02-21 2:06 UTC (permalink / raw)
To: 9fans
Then, I tried to use leak(1) following the man page.
term% leak -s marsv
leak -s 563 564 565
term% leak -b marsv|rc|page
/sys/lib/acid/pool:1: (error) pushfile: /sys/src/libc/port/pool.acid: '/sys/src/libc/port/pool.acid' does not exist
/sys/lib/acid/leak:4: (error) pushfile: /sys/src/libc/port/pool.acid: '/sys/src/libc/port/pool.acid' does not exist
<stdin>:2: (error) no function leakdump
aux/acidleak: no allocated data region
page: short read reading <nil>
I must be doing something fool...
Kenji
^ permalink raw reply [flat|nested] 18+ messages in thread
[parent not found: <uncover@beat.cc.titech.ac.jp>]
* Re: [9fans] output of ps(1) memory usage
@ 2003-02-21 2:34 okamoto
2003-02-21 2:37 ` Russ Cox
0 siblings, 1 reply; 18+ messages in thread
From: okamoto @ 2003-02-21 2:34 UTC (permalink / raw)
To: 9fans
[-- Attachment #1: Type: text/plain, Size: 537 bytes --]
Wao!
I did by the command of
term% leak -b marsv | rc | page
and waited about 2 minutes, I got a wonderfull image of memory
usage.
I have 2/3 of dark blue region, separated into major three parts,
and 1/3 of yellow region, and very very small but many parts od
bright blue, and small amounts of dark or bright red (not easy to
distinguish them). So, the main anxious of mine, that is large
part of red region, is disappeared.
I appreciate the developpers of Plan 9 to provide us such a nice
tool of leak(1).
Kenji
[-- Attachment #2: Type: message/rfc822, Size: 1925 bytes --]
From: "Russ Cox" <rsc@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] output of ps(1) memory usage
Date: Thu, 20 Feb 2003 21:08:02 -0500
Message-ID: <e0055b32a4d103d81f290a0b8ef6e2b8@plan9.bell-labs.com>
cd /sys/src/libc/port
mk pool.acid
Then try it.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [9fans] output of ps(1) memory usage
@ 2003-02-21 2:43 David Presotto
0 siblings, 0 replies; 18+ messages in thread
From: David Presotto @ 2003-02-21 2:43 UTC (permalink / raw)
To: 9fans
> Is there an easy way to determine the amount of memory
> really inuse (or physically mapped?) within a process?
cat /proc/<pid>/segment. The first number is the
range, the second is the reference count. The ref will help
you figure out how many other procs are using the
segment. For example:
presotto@presto-home% ps|grep rio
presotto 14 0:00 0:03 752K Rendez rio
presotto 113 0:00 0:00 752K Pread rio
presotto 114 0:00 0:00 752K Pread rio
presotto 115 0:00 0:00 752K Rendez rio
presotto 116 0:00 0:00 752K Pread rio
presotto 117 0:00 0:00 752K Pread rio
presotto 177 0:00 0:00 752K Await rio
presotto@presto-home% cat /proc/113/segment
Stack 7efff000 7ffff000 1
Text R 00001000 0002d000 7
Data 0002d000 00036000 7
Bss 00036000 000bd000 7
There are 7 rio's...
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [9fans] output of ps(1) memory usage
@ 2003-02-21 3:09 okamoto
0 siblings, 0 replies; 18+ messages in thread
From: okamoto @ 2003-02-21 3:09 UTC (permalink / raw)
To: 9fans
[-- Attachment #1: Type: text/plain, Size: 74 bytes --]
Yeah!
I found huge dark blue region under the page window. ☺
Kenji
[-- Attachment #2: Type: message/rfc822, Size: 2050 bytes --]
From: "Russ Cox" <rsc@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] output of ps(1) memory usage
Date: Thu, 20 Feb 2003 21:37:00 -0500
Message-ID: <724f71d54fac61e0a04f73fcf0691bf8@plan9.bell-labs.com>
The picture can be useful sometimes, but
more useful is the text output (drop the -b flag),
which will give you acid commands to list
the places where the leaked blocks were allocated.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [9fans] output of ps(1) memory usage
@ 2003-02-21 5:47 YAMANASHI Takeshi
2003-02-21 5:55 ` Russ Cox
0 siblings, 1 reply; 18+ messages in thread
From: YAMANASHI Takeshi @ 2003-02-21 5:47 UTC (permalink / raw)
To: 9fans
> > Is there an easy way to determine the amount of memory
> > really inuse (or physically mapped?) within a process?
>
> cat /proc/<pid>/segment. The first number is the
Thank you, all.
I have mistakenly thought that the output of ps/segment
concerns about the virtual memory, not physically mapped.
Now that I understand the ps/segment output correctly,
I revise my question as follows:
Is there a way to determine the amount of swapped pages
of a process? I just want to complete the equation,
virutal memory usage of a process =
swapped or not paged in + physically mapped
--
YAMANASHI Takeshi
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [9fans] output of ps(1) memory usage
2003-02-21 5:47 YAMANASHI Takeshi
@ 2003-02-21 5:55 ` Russ Cox
0 siblings, 0 replies; 18+ messages in thread
From: Russ Cox @ 2003-02-21 5:55 UTC (permalink / raw)
To: 9fans
/proc/pid/segment shows you virtual memory allocation,
not physical. There is no way to find out which pages
in a process are swapped and which are not at a per-page
granularity. Of course, if /dev/swap tells you nothing is
swapped out, then nothing is swapped out. It is also hard
to tell what is not yet paged in.
You could walk around in the kernel's page tables,
but that's not portable and not very clean.
Russ
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [9fans] output of ps(1) memory usage
@ 2003-02-21 7:09 YAMANASHI Takeshi
2003-02-21 15:06 ` Russ Cox
0 siblings, 1 reply; 18+ messages in thread
From: YAMANASHI Takeshi @ 2003-02-21 7:09 UTC (permalink / raw)
To: 9fans
> /proc/pid/segment shows you virtual memory allocation,
> not physical.
I still had mistaken without your explanation.
Segment gives virtual memory information and `ps' physical.
I feel fine now.
--
YAMANASHI Takeshi
^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2003-02-21 15:06 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-02-21 0:51 [9fans] output of ps(1) memory usage okamoto
2003-02-21 1:10 ` Russ Cox
2003-02-21 1:18 ` rob pike, esq.
2003-02-21 2:23 ` David Presotto
2003-02-21 1:55 okamoto
2003-02-21 2:06 okamoto
2003-02-21 2:08 ` Russ Cox
[not found] <uncover@beat.cc.titech.ac.jp>
2003-02-21 2:27 ` YAMANASHI Takeshi
2003-02-21 2:30 ` Russ Cox
2003-02-21 2:42 ` Scott Schwartz
2003-02-21 2:34 okamoto
2003-02-21 2:37 ` Russ Cox
2003-02-21 2:43 David Presotto
2003-02-21 3:09 okamoto
2003-02-21 5:47 YAMANASHI Takeshi
2003-02-21 5:55 ` Russ Cox
2003-02-21 7:09 YAMANASHI Takeshi
2003-02-21 15:06 ` Russ Cox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).