And I've blogged about it at
http://mbruning.blogspot.com/2009/03/faster-memstat-for-mdb.html
max
Ben Rockwood wrote:
m...@bruningsystems.com wrote:
Hi Jim,
Jim Mauro wrote:
mdb's memstat is cool in how it summarizes things, but it takes a very
long time to run on large systems. mems
m...@bruningsystems.com wrote:
> Hi Jim,
> Jim Mauro wrote:
>>
>> mdb's memstat is cool in how it summarizes things, but it takes a very
>> long time to run on large systems. memstat is walking page lists, so
>> it should be quite accurate.
>> If you can live with the run time of ::memstat, it's cu
Hi Jim,
Jim Mauro wrote:
mdb's memstat is cool in how it summarizes things, but it takes a very
long time to run on large systems. memstat is walking page lists, so
it should be quite accurate.
If you can live with the run time of ::memstat, it's currently your
best bet for memory accounting.
I
Jim Mauro wrote:
> Hi Ben - The difficulty in getting accurate memory accounting has to
> do with shared memory pages. Every process that has a shared page
> mapped to its address space gets charged (in terms of RSS measurements).
>
> I tend to use kstats (kstat -n system_pages) to get an idea of h
rickey c weisner wrote:
> On Sat, Mar 28, 2009 at 03:31:59PM -0700, Ben Rockwood wrote:
>
>> unix:0:system_pages:pagesfree 7954235 <--- 31,816,940 (31071 MB)
>>
> Free (cachelist) + Free (freelist) = 30992 + 73 = 31065 MB
>
>> unix:0:system_pages:pp_kernel 379926 <-
Hi Ben,
Ben Rockwood wrote:
m...@bruningsystems.com wrote:
Hi Ben,
Ben Rockwood wrote:
I'm curious as to why memory statistics seems to be very difficult to be
accurate about. If you use kstats, mdb ::memstat, and add up VSZ/RSS
from ps, you get numbers that are different, although cl
Hi Jim,
Jim Mauro wrote:
I've often struggled with this. Memory observabilty is kind of a gap
in Solaris today. DTrace is great for tracking active memory allocations
and frees, but often all you want is a memstat-like snapshot. kstats
get you close to that, but lack the granularity of memstat
Hi Ben - The difficulty in getting accurate memory accounting has to
do with shared memory pages. Every process that has a shared page
mapped to its address space gets charged (in terms of RSS measurements).
I tend to use kstats (kstat -n system_pages) to get an idea of how much
the kernel is usi
On Sat, Mar 28, 2009 at 03:31:59PM -0700, Ben Rockwood wrote:
> unix:0:system_pages:pagesfree 7954235 <--- 31,816,940 (31071 MB)
Free (cachelist) + Free (freelist) = 30992 + 73 = 31065 MB
> unix:0:system_pages:pp_kernel 379926 <--- 1,519,704k (1484 MB)
Kernel + Page cache =
m...@bruningsystems.com wrote:
> Hi Ben,
> Ben Rockwood wrote:
>> I'm curious as to why memory statistics seems to be very difficult to be
>> accurate about. If you use kstats, mdb ::memstat, and add up VSZ/RSS
>> from ps, you get numbers that are different, although close.
>>
>> Can anyone shed s
Hi Ben,
Ben Rockwood wrote:
I'm curious as to why memory statistics seems to be very difficult to be
accurate about. If you use kstats, mdb ::memstat, and add up VSZ/RSS
from ps, you get numbers that are different, although close.
Can anyone shed some light on why this is? I'm assumed that ::m
Mike,
Thanks for your answers,
I did the following,
--- En date de : Jeu 5.3.09, Mike Gerdts a écrit :
De: Mike Gerdts
Objet: Re: [perf-discuss] Memory
À: "elkhaoul elkhaoul"
Cc: perf-discuss@opensolaris.org
Date: Jeudi 5 Mars 2009, 15h56
On Thu, Mar 5, 2009 at 8:31 AM
On Thu, Mar 5, 2009 at 8:31 AM, elkhaoul elkhaoul wrote:
> Hello,
>
>
> Application running on Solaris10 use the all memory (100%) more than 80GB
> (The machine has only 8Gb of physical memory and 16 of swap),
>
> prstat -a
> .
> NPROC USERNAME SIZE RSS MEMORY TIME
> CPU
Ouch, mistakenly I posted a private response to list.
Worst of it: Most URL's are not yet online.
More infos at a given time in separate announcements.
I apologize to world for this mistake :(
%martin
___
perf-discuss mailing list
perf-discuss@open
>> Bob
>> ==
>> Bob Friesenhahn
>> bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
>> GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Martin Bochnig,
Sun CertifiedSytemAdmin for Solaris 10, 9, 8
Sun CertifiedNetworkAdmin
"some users"?
On Thu, Feb 12, 2009 at 6:23 PM, Bob Friesenhahn
wrote:
> I checked the bug tracker for 'top' and did not see any memory leak bug
> listed so I opened up SourceForge bug ID 2593511 so that the top maintainer
> is aware of the issue.
>
> http://sourceforge.net/tracker/index.php?fun
I checked the bug tracker for 'top' and did not see any memory leak
bug listed so I opened up SourceForge bug ID 2593511 so that the
top maintainer is aware of the issue.
http://sourceforge.net/tracker/index.php?func=detail&aid=2593511&group_id=72892&atid=536042
Please add any additional info
On Thu 12 Feb 2009 at 09:12AM, Peter Tribble wrote:
> On Thu, Feb 12, 2009 at 3:05 AM, Bob Friesenhahn
> wrote:
> > On Thu, 12 Feb 2009, Martin Bochnig wrote:
> >>
> >> So, one day later they had grown further, but here comes the absolute
> >> HAMMER: One top process was at 1340MB!!!
> >
> > Your
On Thu, Feb 12, 2009 at 3:05 AM, Bob Friesenhahn
wrote:
> On Thu, 12 Feb 2009, Martin Bochnig wrote:
>>
>> So, one day later they had grown further, but here comes the absolute
>> HAMMER: One top process was at 1340MB!!!
>
> Your 'top' program obviously has some sort of bug
That would be bug 6777
On Wed, Feb 11, 2009 at 9:37 PM, Jason King wrote:
> On Wed, Feb 11, 2009 at 9:24 PM, Martin Bochnig wrote:
>> Hi!
>>
>> On Thu, Feb 12, 2009 at 4:05 AM, Bob Friesenhahn
>> wrote:
>>
>>> Your 'top' program obviously has some sort of bug but otherwise I don't see
>>> anything necessarily out of t
Bob Friesenhahn wrote:
> maybe a bug in top ...
And well, I would not care about what top does or doesn't report.
Problem is: It is not just a game of numbers. This box got
unbelievably lluuugiih until I killed most
memory-consuming top- and wget-processes.
Then things we
On Wed, Feb 11, 2009 at 9:24 PM, Martin Bochnig wrote:
> Hi!
>
> On Thu, Feb 12, 2009 at 4:05 AM, Bob Friesenhahn
> wrote:
>
>> Your 'top' program obviously has some sort of bug but otherwise I don't see
>> anything necessarily out of the ordinary in the top listings.
>
>
> Does this explain why
Hi!
On Thu, Feb 12, 2009 at 4:05 AM, Bob Friesenhahn
wrote:
> Your 'top' program obviously has some sort of bug but otherwise I don't see
> anything necessarily out of the ordinary in the top listings.
Does this explain why a wget process grew to 2.2GB (where I killed it) ??
Then wget must hav
On Thu, 12 Feb 2009, Martin Bochnig wrote:
/usr/bin/top showed me that one of the 5 wget sessions I had started a
week ago (for fetching opensolaris.org, sdlc.com/osol, genunix.org and
a few LinUX mirrors) had grown to 2GB!!! And one day later it was
2.2GB. So I killed that wget pid and started
If it is a FAQ it deserves to be in some Solaris FAQ
http://www.genunix.org/wiki/index.php/Category:FAQ
This message posted from opensolaris.org
___
perf-discuss mailing list
perf-discuss@opensolaris.org
Thank you very much, great article.
This message posted from opensolaris.org
___
perf-discuss mailing list
perf-discuss@opensolaris.org
I think this is a FAQ which is covered by an article I wrote 12 years ago
and updated 10 years later...
"Help, I've Lost My Memory..."
http://perfcap.blogspot.com/2005/10/help-ive-lost-my-memory-updated.html is
an updated version of
http://www.itworld.com/Comp/2377/UIR951001perf/
Adrian
On 7/7/
Thanks for reply, it's very interesting for me. For night's memory loss
detection I look orca graphics (memory down starttime==backup script
starttime). At night only backup script is running on my system. It contain 5
strings like "tar cpf etc.tar /etc/*" and e.t.c. When I login to server af
Hi Alex:
These leaks in tar aren't enough to consume 1GB of memory. When
applications leak memory, that memory will be returned to the system
once the application exits.
What are you using to measure the amount of memory consumed by your
system? Can you explain why you think it is leaking memor
On 4/23/06, Tao Chen <[EMAIL PROTECTED]> wrote:
> On 4/23/06, Sh <[EMAIL PROTECTED]> wrote:
> > I have some questions about the prstat utility output
> > For example if I do prstat -a:
> > ---cut
> > NPROC USERNAME SIZE RSS MEMORY TIME CPU
> > 40 wraith983M 3
On 4/23/06, Sh <[EMAIL PROTECTED]> wrote:
I have some questions about the prstat utility outputFor example if I do prstat -a:---cut NPROC USERNAME SIZE RSS MEMORY TIME CPU40 wraith983M 399M79% 0:48:04 15%
48 root 201M 90M
Mike Marty wrote:
Hello,
I've noticed that the OpenSolaris seems to support NUMA memory allocation
(memory placement optimization) for Opteron machines. Specifically the lgroups
are created in this platform-specific file:
/usr/src/uts/i86pc/os/lgrpplat.c
However the corresponding Sparc pla
You'll undoubtedly get a more detailed response from an expert - but
basically on SPARC, it is able to determine the number of lgroups from
the platform code, so it doesn't need to do the probing tricks that it
has to do on the Opteron.
cheers,
steve
Mike Marty wrote:
Hello,
I've noticed th
33 matches
Mail list logo
