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
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 ::memstat
is the most accurate me
12 matches
Mail list logo
