David Collier-Brown wrote:
Sean Liu wrote:
Now - let's take a look from another angle:
a. When people take a look at vmstat output, they don't expect
an exact number of bytes of free memory, they need a rough number
however. So some reasonably accurate number would be good enough.
Richard Elling <richard.ell...@gmail.com> replied:
| good enough may be reasonably achievable, just subtract arcstats:c_min
[big snip]
| We lost the clue with the invention of demand paged virtual memory
| 30 years ago.
Actually Sean's asking for a clue about the *virtual* memory behavior.
But the vmstat free column shows the size of the free list, which
does tell you about the virtual memory behaviour, it just doesn't
tell you much about capacity planning. memstat will be closer
to being useful, but is very intrusive.
Sean Liu wrote:
Richard,
Thanks for the beer analogy :-)
I enjoyed drinking it with you :-)
But I think you misunderstood my question.
I'll also use the beer analogy:
1. I have certain bottle of beers in my fridge (total memory)
2. Some guests are drinking beers ( current apps consuming memory )
3. A bunch of new friends just called they are coming to the party and
requested N bottles of beers. (new app requirement)
4. Once upon a time I had a record that could tell me how much beer there are
in the fridge. (vmstat freemem w/o ZFS)
ok so far... though the number of beers are the store is not
dynamic in Solaris like it is in OSX or Windows. I gather
you are trying to avoid going to the store for more beer.
5. However a new guest just came and claimed all the beer in the fridge is his
even though he would be nice enough to give his beer to others if so they
request. (ZFS ARC)
No, UFS also did this. Prior to SunOS 4, the RAM reserved for
UFS was fixed in the kernel. With SunOS 4, UFS was changed to
use the page cache. It will give back the pages, just like the ARC
does. But unlike the ARC, there is no accounting of the use of
the UFS page cache. For example, with the ARC you can see
the cache hit rates and the various boundaries of the algorithms.
With UFS, there is no similar instrumentation. This does affect
your performance, even if you don't hit a RAM shortfall, but you
have no idea how to predict the performance impact nor do you
have a way to properly plan or manage the UFS cache size. With
the ARC you now know the efficiency of your cache and thus
can do a better job of sizing it.
6. But now I lost track how much beer there are in the fridge and if I need to
start serving vodka instead/go buy some more. (Roughly just how much memory do
I have to give out to apps without inducing paging/memory upgrade?)
vmstat free doesn't answer this question. It has been used as a
proxy, with a suitable margin. Going forward, it will be less
and less useful -- a real capacity planning tool is needed.
My question right now is NOT how much memory I need - Let's say I do know I need X GB
ISM for my Oracle DB or Y GB for my JavaVM, my question is "Do I have enough RAM on
my system do accomodate that without causing paging?"
paging is only one performance barrier. There are others, such
as the number of large pages, which vmstat does not report,
but is important for capacity planning. Applications themselves
are also becoming more sophisticated as more and more will
dynamically manage their memory use.
Once upon a time I could answer the question with some confidence.
I can't answer it anymore.
A decent capacity planning tool would be useful, but systems
management has never been Sun's forte. The UFS change for
the free list accounting equation merely postponed the inevitable.
Fortunately, with Dtrace and kstat, it is feasible for someone to
create such a tool without changing kernel source. Unfortunately,
the demand for such a tool decreases with the price of memory.
-- richard
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org
