Hi Elkhaoul,
elkhaoul elkhaoul wrote:
Thanks Chad,
It seems that it will not return memory to applications, in fact, when
the kernel/buffer cache use the all memory, Applications use swap and
The scan rate is very high :
sar -g 3 ==>
pgscan/s = 5264
Now, I have this :
### top
last pi
elkhaoul elkhaoul wrote:
> ** *Is this any tools to know who use the big portion of RAM ?*
> ** *Thanks in advance
> *
>
Have you tried:
echo "::memstat" | mdb -k
Do this a few times over some interval to see if the kernel is
growing.
Is there a reason you
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
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,
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, alt
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
Responding to myself...
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 ti
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 lar
Hi Jim,
Jim Mauro wrote:
Back to memory consumers. We have;
- The kernel
- User processes
- The file system cache (which is technically part of the kernel,
but significant enough such that it should be measured
seperately.
tmpfs (i.e., /tmp, /var/run, and /etc/svc/volatile on my system) also
