Operating System - HP-UX
1829594 Members
1667 Online
109992 Solutions
New Discussion

Continuation of Shared Memory thread

 
SOLVED
Go to solution
Belinda Dermody
Super Advisor

Continuation of Shared Memory thread

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
6 REPLIES 6
Stephen Keane
Honored Contributor
Solution

Re: Continuation of Shared Memory thread

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.
Stephen Keane
Honored Contributor

Re: Continuation of Shared Memory thread

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

Pete Randall
Outstanding Contributor

Re: Continuation of Shared Memory thread

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

Pete
Mark Nieuwboer
Esteemed Contributor

Re: Continuation of Shared Memory thread

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

TwoProc
Honored Contributor

Re: Continuation of Shared Memory thread

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.
We are the people our parents warned us about --Jimmy Buffett
Belinda Dermody
Super Advisor

Re: Continuation of Shared Memory thread

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