The O/S is HP UX 11.00. When my users log off at the end of the day I run "swapinfo" and it says that 60% of memory is still being utilized. There are no processes running from thier session earlier in the day. Is there a way to clean up this 60% of memory being used?
First suspicions is your buffer cache and not a leaky app. Only MS can make that big of a sieve.
Run the following:
kmtune -l | more and look for bufpages and NBUF. If they are set to 0 (zero) dynamic buffer cache is on. Then you have to look at dbc_max_pct and dbc_min_pct. They default to 50 and 5 respectively. There's your memory.
Otherwise, do you have glance on the system. /opt/perf/bin/glance. HP's memory utils outside of glance are really weak.
If you're looking at the output of swapinfo, doesn't that just refer to paging (swap) space?
If so I don't think that adjusting the size of the buffer cache will affect it.
bgdak - Do you mean that your paging (swap) space is still being utilised when the machine is quiet or do you mean that your free memory is lower than you expected when the box is quiet?
Mike
Want to get great answers to your Tek-Tips questions? Have a look at faq219-2884
I assume bgdak has been looking at the available(free) memory in swapinfo.
HP's buffer cache is only dynamic one way, up. It's been that way since 10.01. (oh, and going to be fixed since then as well)
I have seen this many times on quiet systems. 60% utilized = 50% taken by the buffer cache and 10% by the OS and remainder little stuff running.
run this command
echo bufpages/D | adb /stand/vmunix /dev/kmem
You'll get this
bufpages:
bufpages: 13107 --- your number
That's the number of 4k pages of buffer cache real time.
Then use bc and 13107*4096/1024/1024 = 51MB <-- Your number is????
Now, I am not saying change it. It depends on what the applications are -- Oracle: best practice is to run at 5% and 10% but say Universe DB: it needs to stay as high as possible (Oracle caches on it's own Universe does not).
Mike - You are absolutly correct about the swap information not changing.
However IF the buffer cache is not shrinking dynamically, and you were to change dbc_max_pct down the memory utilization would go down -- BUT the mem and dev swap would remain the same.
Shows how long it's been since I looked at the output of swapinfo..... I use SAR, vmstat and glanceplus to check stuff generally.
I wouldn't generally worry about buffer cache using all of the available free memory - that's what it's meant to do. The best use of free memory is usually buffer cache; you only need enough free memory to guarantee starting the next process without triggering paging activity.
As you say, it's only a problem for certain configurations - Oracle is the best example but this is only true for "large" systems with "a lot" of memory and a reasonably static number of processes - where CPU utilisation is being needlessly hit by the bookkeeping needed to grow and shrink the cache.
I'm not aware of any rules that define "large" and "lot" since this will vary depending on the speed of the processor.
If this is an Oracle database server and you decide to fix the size of the buffer cache then remember to assign the memory to Oracle's SGA - there's no point in having free memory. Free memory is just that - free; wasted in other words. Either assign it to Oracle's SGA let HPUX manage the size of the cache itself.
Mike
Want to get great answers to your Tek-Tips questions? Have a look at faq219-2884
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.