Shmmax limit?

[Steven Richards]

Hi,

I'm having a problem with shmmax - it was set to 4294967296, I needed to adjust some kernel params for the oracle team and SAM informed me that shmmax had been lowered to it's limit of 1073741824 and now I can't set it higher than this, it keeps complaining that this is the highest possible value, which clearly it isn't because it says here http://docs.hp.com/en/B2355-60105/shmmax.5.html that it can be massive. So what is stopping it being big enough? Is there another kernel parameter that limits shmmax?

Many thanks for your help.

Steve.

[A. Clay Stephenson]

When you don't bother to mention your OS version, it's difficult to offer specific help. The problem is not with the kernel but rather with SAM itself. Look for the latest SAM cumulative patch for your OS version and install it. Now, the 1GiB limit may be exceeded easily by all 64-bit application but if you are running a 32-bit application then the application itself has to be modified.

[Don Morris_1]

As Mr. Stephenson pointed out -- more information is needed.

You're referencing the 11iv2 (11.23) man page -- but that doesn't mean you're running that release. Release (and kernel bits) are important here... since you could be on 11.11 in a 32-bit kernel (where the shmmax *is* limited to 1Gb).

If you're on 11.11 and "getconf SC_KERNEL_BITS" returns 64, I agree that this may be a SAM bug and would recommend (as a workaround) using "kmtune shmmax=4294967296" directly. shmmax is dynamic on 11.11, so you don't need a kernel rebuild or anything for this to take effect. If 11.11 and a 32-bit kernel, SAM is right -- and I'd suspect that your system file was attempting to set the tunable value to the higher value by hand [but it would have been ignored anyway].

If you're on 11.23 or higher, use "kctune shmmax=424967296" and you definitely have a SAM issue.... though I can't find any reference to any such issue at this time [otherwise I'd try to point you at a patch].

Please reply with details, and what kmtune/kctune reports depending. Thanks.

[Steven Richards]

Apologies for the lack of o/s info, sometimes you just assume everyone knows what version you are running! :-D

This system is an 11.11 64 bit HP-UX environment. So as you rightly pointed out referencing the 11iv2 man page is not really that helpful.

The strange thing is that the value at some point was set to 4294967296 but for some reason SAM insists it's not allowed to be that high.

I decided to take your advice and set it using kmtune (btw, you missed the -s option) but it's still showing the new value as planned and not current.

kmtune | grep shmm
shmmax 1073741824 Y 4294967296
shmmni 512 - 512

shoudln't it take effect immeadiately or have I missed something really obvious?

Many thanks again, Steve.

[Don Morris_1 · Accepted solution]

I think you need "kmtune -u -s shmmax=4294967296" [-u for "update immediately" per http://docs.hp.com/en/B2355-60127/kmtune.1M.html ].

Sorry that I've apparently forgotten the kmtune flags and didn't specify this up front.

Ah-ha! And some more digging may have found our culprit.. its an old issue, but there _was_ a case where the /usr/conf/master.d/sysv-shm file had the wrong range statement for shmmax on 64-bit 11.11... resulting in SAM [but not kmtune which gets the limits elsewhere] limiting shmmax to the 32-bit value (as you've got).

Do you perchance have PHKL_30196 (latest) or PHKL_24032 (original patch... PHKL_30196 really just adds support for the ShmemExtensions optional product, so you don't really need it unless you want to install ShmemExtensions for a higher shmmni value)? If not... that's almost certainly your problem... please install it the next chance you get. Until then, using kmtune directly is the workaround.

[Steven Richards]

Thanks Don for the reply.

I'll forgive you for not remembering all the flags for kmtune.....this time ;-) kmtune -u -s has done the trick.

Thanks for the info on the patch, we will look at installing at the next available opportunity.

All the best - Steve.

[A. Clay Stephenson]

and if you don't install PHKL_30196 (or at least its predecessor), SAM will helpfully bring shmmax back into what it considers a valid range the next time you try to use it to tune/build a new kernel.