Operating System - HP-UX
1748158 Members
4242 Online
108758 Solutions
New Discussion юеВ

Shared memory table nearly full

 
Matt Mumford
Occasional Advisor

Shared memory table nearly full

Hey all, in glance I am getting a 'Shared Memory Table is nearly full' message. Then I get a 'end of shared memory table full condition'. This started about four weeks ago and I am lost on what to look for. The pattern seems to start around 12:30pm EST and last for a couple hours. I am runn a N4000 with 8.5 GB of memory and HP 11.11. I am not expert by any means, so could someone please HELP.

Matt
3 REPLIES 3
Pete Randall
Outstanding Contributor

Re: Shared memory table nearly full

Matt,

You should think about increasing the kernel parameter "shmmni".


Pete

Pete
Bill Hassell
Honored Contributor

Re: Shared memory table nearly full

The problem is with your 32bit applications. There is only one map for shared memory for all programs and it becomes fragmented when you stop and start various programs that use shared memory. And shared memory segments that were in use by programs that were killed with kill -9 will occupy this space until a reboot (kill -9 should always be avoided if at all possible for database and other complex programs). You can start by looking at the shared mmemory table assignments:

ipcs -bmop

Now you can remove segments that are no longer in use but this requires detailed knowledge of the programs that are currently running. The NATTCH field shows a process count that is using this segment. Anything > 0 means that it is in use. But NATTCH=0 is not always a sign that the segment is no longer used. It's possible that some processes may be scheduled in the near future that will indeed use this segment. You can also check the CPID, the process ID of the creator of this segment, and LPID, the last process ID that either attached or detached from the segment. The command ipcrm can remove a segment to free some memory, but if the segment is still in use, the affected programs will crash.

The safest way to handle this situation is to reboot, then have your programmers or DBAs look at ways to properly shutdown the programs while running and have the shared memory segments removed. There are two other solutions: memory windows and changing the 32bit programs to 64bit programs. Memory windows is probably the simplest solution. This gives each group of programs that need shared memory their own private memory map so that fragmentation is virtually eliminated.

The 32bit shared memory map is used by many different programs such as fbackup and also includes very small pieces of memory used by daemons and other system programs. If you'd like to see the complete usage (in memory order), get a copy of shminfo from: ftp://contrib:9unsupp8@hprc.external.hp.com/sysadmin/programs/shminfo/


Bill Hassell, sysadmin
Matt Mumford
Occasional Advisor

Re: Shared memory table nearly full

Thanks for the response guys. I reboot the system Friday and it started again today. The only thing I can think of is that we have grown some .Net applications that call an ODBC pacakage called UniObjects that inturn uses a UNIX login. It is a many to few situation of .Net user to UNIX accounts. I am wondering if the same UNIX account is called many times will this fill up the shared memory? At this point I think I need to increase the shared memory as we have 8.5 of physical memory and based on glance use 65% of the physical and 49% of the swap on an average. What do you guys think? What all goes into increasing shared memory? reboot? etc?

Matt