Shared Memory Question

[James Colby]

Hello everyone,

I have a few questions about shared memory in HP-UX 11.0.

1) Is there any way for me to find out how much shared memory is available on my system now. I have been working on some DB tuning and I would like to be able to see how much free shared memory I have available to assing to the SGA of an oracle DB.

2) The kernel parameter SHMMAX, does that refer to the total amount of shared memory available to the system? Or is just the the max size that one shared memory segment can be?

Thanks You!,
James Colby

[Christopher McCray_1]

Hello,

1. You can use glance to find this.

2. From the web page: http://docs.hp.com/hpux/onlinedocs/939/KCParms/KCparam.ShMmax.html

Description
shmmax defines the system-wide maximum allowable shared memory segment size in bytes. Any shmget() system call that requests a segment larger than this limit returns an error (see HP-UX Reference entry shmget(2))

Hope this helps

Chris

[James Murtagh · Accepted solution]

Hi James,

1) The real question is how much contiguous shared memory you have available. You can find this using adb but it is much easier using shminfo. If you don't have it it's available here:

ftp://contrib:9unsupp8@hprc.external.hp.com/sysadmin/programs/shminfo

Just run it without any options and it will describe your shared memory layout/limits etc. i.e. for the maximum contigous segment:

# shminfo|grep Largest
Largest free segment: 1048576 Kbytes (Window id 0 (global) quadrant 2)

Please note this really only relates to 32 bit apps, 64 bit apps shouldn't have too many restrictions, apart from the ones you set yourself in the kernel.

2) It refers to the maximum segment size.

Regards,

James.

[Steven E. Protter]

The ipcs command shows shared memory segments.

SHMMAX refers to the total amount of shared memory. It can never be raised past 25% of total memory, which is defined as physical memory plus swap.

SHMSEG is the amount of shared memory segments available.

ipcs command ties in nicely.

For most HP-UX boxes serving Oracle, I give up tuning and crank shared memory up to that 25% figure. The purists don't like that, but it works and Oracle is a hungry, hungry application.

SEP

[Bill Hassell]

The biggest obstacle in shared memory for Oracle is 32bit programs!! By default, the largest segment can only be 960 megs, or by relinking, 1750 megs. But for 32bit programs (regardless of whether HP-UX is 64bit or 32bit) they must all fight for one addressing area and this area can easily become fragmented, especially when shared memory programs are killed or not working correctly. A workaround is memory windows to give a group of applications their own private window, but the real solution is to run 64bit Oracle where there are no practical limits.

As any DBA will tell you, they would like hundreds of megs for SGA, but will fail because of the issues mentioned above. Note that your DBA can request shared memory that is larger than RAM and portions of the SGA will be paged out. This can make Oracle run 20 to 100x slower which is why 4Gb is a basic minimum for Oracle RAM.

Read the two white papers in /use/share/doc on process management and memory management.

[James Colby]

I downloaded the utility that Mr. Murtagh suggested and I ran it. I got this as part of the output:

Largest free segment: 1048576 Kbytes (Window id 0 (global) quadrant 2)

so it would appear that I have plenty of Shared memory available. I am however getting some errors stating that I do not enough free shared memory to run oracle processes. Do I need to install the the memory_magic patch to access this free shared memory? Or is it because 32bit oracle can't address that space?

[James Murtagh]

Hi James,

Ideally read the memory management white paper Bill mentioned. It is available here:

http://www.docs.hp.com/hpux/onlinedocs/5965-4641/5965-4641.html

The example I gave perhaps wasn't the best. Look at the bottom of the shminfo output - it describes the allocation policy. Note Quadrant 2 space is only available to SHMEM_MAGIC executables.

For normal executables its uses Q4 first then Q3. The shminfo output shows how much each of these quadrants is in use, and the FREE segments. For example, the last description under Q4 allocation shows:

Q4 0x02cd9c00.0xc4d26000-0xefffffff 707432 FREE

So I have ~700MB free in that quadrant. Basically I have very little shared memory in use. If you are using shared memory for Oracle SGAs you might see no free space in this quadrant but a larger free section in Q3, the last quadrant an allocation will be applied to.

Once you have a look at the White Paper this will make more sense.

Regards,

James.

[Caesar_3]

Hello!

You should check with the oracle the changes
that better to made to the kernel that
oracle will work well.

Caesar

[Bill Hassell]

As James pointed out, the 1048576 Kbytes is available only to 32bit executable programs that were linked with the SHARED_MAGIC option. This means that you must relink all the Oracle executables with the SHARED_MAGIC feature. Note that you must never use kill -9 on any of the Oracle executables since this can leave unattached memory segments and Oracle will be unable to allocate memory again. ipcrm can remove these segments but never remove any segments unless you have properly stopped all the processes that use shared memory.

Trying to use Oracle in 32bit mode for all but the smallest databases and user count will require a lot of careful fitting and management of the very lmited shared memory address space. Even if you have 8Gb of RAM, the 32bit executables cannot access data beyond the small limitations of a 32bit program.