topic Re: Continuation of Shared Memory thread in Operating System - HP-UX

Continuation of Shared Memory thread

Belinda Dermody — Thu, 15 Sep 2005 10:03:44 GMT

I received some good answers on this yesterday and now a followup.

My Sybase DBA's say they are only interested in increasing the shmmax parameter in the kernel, right now it is setting at 536,870,912 and this was set when we had 2g of system memory and now we have 4gig of system memory. They say that I should reset it to the max of 4,294,967,296. Would this be OK to do and what is the meaning of Y below the Dyn, I still have to rebuild the kernel and reboot the system for the change to take place is this correct.

Parameter Current Dyn Planned
=============================================
shmmax 536870912 Y 536870912

Re: Continuation of Shared Memory thread

Stephen Keane — Thu, 15 Sep 2005 10:11:18 GMT

shmmax can be altered dynamically (the Y under Dyn) without rebuilding the kernel. Of course if you want a permanent change, you would rebuild the kernel. SAM and kmtune use the settune() system call to change shmmax.

Re: Continuation of Shared Memory thread

Stephen Keane — Thu, 15 Sep 2005 10:14:35 GMT

e.g.

kmtune -s shmmax=xxx
kmtune -u shmmax

Dynamically updates shmmax w/out rebuilding the kernel or rebooting.

Check it using

kmtune -l -q shmmax

Re: Continuation of Shared Memory thread

Pete Randall — Thu, 15 Sep 2005 10:19:27 GMT

We run Informix but the idea is the same, I suspect. Our shmmax is set to 4,294,967,296 with no ill effects at all. The DB likes to have all that room to work.

Pete

Re: Continuation of Shared Memory thread

Mark Nieuwboer — Thu, 15 Sep 2005 10:22:08 GMT

Hi,

Why shmmax has nothing to do with how much memory you have on the system. It only has to do how much shared memory you can allocte but if a database need 4 gig of shared memory there is something wrong with the database or the database is to big and you have to consider to go to another database like oracle. and keep in mind that you can't allocted all the memory for shared.

grtz. Mark

Re: Continuation of Shared Memory thread

TwoProc — Thu, 15 Sep 2005 10:22:46 GMT

Yes, it would probably be OK to set it to that.

This doesn't stop them from snagging all the memmory in the box - it just determines how large the largest single segment can be. This generally helps databases run more efficiently than having their managed memory areas cut up all over the place.

Hopefully though - they won't take this to mean that they can allocate 4G of shared memory, singly, or in pieces.

Re: Continuation of Shared Memory thread

Belinda Dermody — Thu, 15 Sep 2005 10:30:25 GMT

Thanks guys as always you have come through quickly and with a lot of good opinions and you always have help this old guy...