filecache_max at 64%

[James R. Ferguson]

Hi Lisa:

> Forgot to add, is there any problem with increasing shmmax? The man pages says to raise if it is below the max and user program are attempthing shmget segments ... and get EINVAL error message.(not happened) It shows 3% usage of the default of 1073741824, would that say the value is adequate since only at 3% usage?

Why do you want to diddle with the current setting? You indicate that you are NOT getting EINVAL errors for 'shmget()' memory segment acquisitions. I'd leave this alone.

Regards!

...JRF...

[Lisa Dingman]

Yes, this only shows 3.1% usage for shmmax. Now filecache_max is at 100%. Could this somehow be related to a DataProtector install. That is the only thing that changed when filecache_max increased yesterday.

# kcusage -d shmmax
Tunable: shmmax
Setting: 1073741824
Time Usage %
=============================================
Tue 06/23/09 15:00 CDT 33554432 3.1
Tue 06/23/09 16:00 CDT 33554432 3.1
Tue 06/23/09 17:00 CDT 33554432 3.1
Tue 06/23/09 18:00 CDT 33554432 3.1
Tue 06/23/09 19:00 CDT 33554432 3.1
Tue 06/23/09 20:00 CDT 33554432 3.1
Tue 06/23/09 21:00 CDT 33554432 3.1
Tue 06/23/09 22:00 CDT 33554432 3.1
Tue 06/23/09 23:00 CDT 33554432 3.1
Wed 06/24/09 00:00 CDT 33554432 3.1
Wed 06/24/09 01:00 CDT 33554432 3.1
Wed 06/24/09 02:00 CDT 33554432 3.1
Wed 06/24/09 03:00 CDT 10469376 1.0
Wed 06/24/09 04:00 CDT 33554432 3.1
Wed 06/24/09 05:00 CDT 33554432 3.1
Wed 06/24/09 06:00 CDT 33554432 3.1
Wed 06/24/09 07:00 CDT 33554432 3.1
Wed 06/24/09 08:00 CDT 33554432 3.1
Wed 06/24/09 09:00 CDT 33554432 3.1
Wed 06/24/09 10:00 CDT 33554432 3.1
Wed 06/24/09 11:00 CDT 33554432 3.1
Wed 06/24/09 12:00 CDT 33554432 3.1
Wed 06/24/09 13:00 CDT 33554432 3.1
Wed 06/24/09 14:00 CDT 33554432 3.1
#

[Don Morris_1]

The system is _supposed_ to cache between filecache_min and filecache_max as needed and accounting for overall system pressure. There is no problem with that -- you should expect filecache usage near 100% in many cases. (Especially when filecache_max is low. Your system is not low... but obviously, there's some significant file traffic moving around that caused the cache to fill up. If that was of the "read (or write) once, never reference again" then as soon as there's pressure... those pages will be the first to go!)

Is there no free memory that you believe the filecache_max represents an incorrect use of RAM?

[Don Morris_1]

Oh, and if you're really paranoid about this -- you don't need to reboot. Set filecache_max to filecache_min (be prepared to see vhand taking cycles) to force the cache to shrink, then revert to the original value if desired.

If you don't believe your filecache should be using that amount of memory in the first place, just set the tunable lower and move on.

[Lisa Dingman]

I think my main issue is trying to find out what made this jump at 2pm yesterday the exact same time as the install of DataProtector. If someone had incorrectly performed the install and tried to install a new cell manager instead of a client install of DataProtector, is that something I could check for. In troubleshooting anything you wonder what was the last thing that happened before the change in 'event' and it could just be a coincidence but seems very odd. I have to reboot tonight anyway for the few kernal changes for our added licenses for our Database so will see what that does. Thank you, I appreciate all your help.

[Lisa Dingman]

Oh my goodness, my apologies to everyone. The change was at 2AM not 2PM and that was when the Database was stopped and restarted to accept the new udtconfig perameters. I cannot believe I didn't see this. SO hopefully when I reboot the system at 3am tommorrow everything shoud be in sync. I guess this didn't seem obvious as the perameters didn't change much as far as a few percent. Hopefully I can report good news tommorrow.

[Lisa Dingman]

Thank you everyone, what a dummy, I just didn't pay attention to the time and connected 02:00 with 2 pm which took me on a wild goose chase. I did reboot and the filecache_max peram is back down to 2%. I learned alot though, have had no training as sys admin wasn't aware of kcusage so a big thanks to all who helped!!Learned alot through this.

[P.J. Cruz]

Lisa we are also a Unidata 7.1.11 customer what is your version? my email is pj.cruz@rcc.edu

[Hein van den Heuvel]

P.J Popped this topic to the top, where I saw it for the first time.

SEP wrote>> The fact that its not 100% used, means its probably big enough.

I would go one step further.
I would argue that the cache is clearly TOO BIG in a general sense, or too big for the available physical memory.

In either case there is no reason to increase, and little or no reason to decrease.

For me a healthy cache setting would fill to 100% and then start to flush out old data to make room for new data. If it does not fill, then it is too big, but that does not really cost anything. Just memory gone unused, which perhaps you can tell a database or such to use.
If it wanted that 100% but was trimmed down to 96% because of more urgent memory pressure, then so bit it. It relinquished the memory like it should. If that is an ongoing struggle, then I suppose you could trim the _MAX some to make it self-limiting/pro-active versus re-active. No big deal... IMHO

Lisa wrote (@19:38:38 ) .. " when filecache_max increased yesterday."
I'm kinda curious what made you increase it considering the replies and explanations earlier.

Lisa wrote (@Jun 25, 2009 14:39:42)
GMT N/A: Question Author
"I did reboot and the filecache_max peram is back down to 2%"

Really? Are you referring to actual use, relatively shortly after a reboot, or was the max actually set to 2% ?!. That would seem very wrong. HPUX 11v3 is very happy and capable to manage much more aggressive cache settings.

A max of 2% would likely be holding back the system, forcing IO's which could be avoided.


fwiw,
Hein van den Heuvel
HvdH Performance Consulting