Author |
Message
|
tso0rxp |
Posted: Tue Aug 03, 2004 7:31 am Post subject: shared memory issue |
|
|
 Voyager
Joined: 07 Jan 2002 Posts: 85
|
Running v5.3 (CSD 6) on Solaris 8 server. Shortly after upgrading to v5.3 we've noticed shared memory decreasing a little bit each day. Eventually, after a week or so from the last recycle of our queue manager, we get to such a low memory condition that other process fail due to insufficient resources.
I've noticed that the processes consuming the greatest amount of memory (and increase in their consumption during the week) are spawned amqzlaa0. There are 5 of them running now but two of them are consuming over 1gb of swap space.
Our unix team also applied a bunch of Solaris kernel patches over the last few weeks.
What I can't determine is what exactly spawned these amqzlaa0 processes. If I knew that I could just stop/start them periodically. As it stands now, I have to recycle the entire queue manager to free up the swap space.
We have Mercator Event server sitting on 2 of our queues waiting for messages so it very well could be this process but when I stop/start the event server it does nothing to free up the shared memory and the spawned amqzlaa0 pids.
This is very difficult for me to track and I'm getting pressure from above to resolve.
Any ideas?? _________________ Bob Perry
MQ Administrator |
|
Back to top |
|
 |
bbburson |
Posted: Tue Aug 03, 2004 7:41 am Post subject: Sun kernel patch |
|
|
Partisan
Joined: 06 Jan 2004 Posts: 378 Location: Nowhere near a queue manager
|
Make sure kernel patch 117000-03 is installed. We had a similar problem with WMQ 5.3, CSD05, where shared memory/semaphores were being eaten up until MQCONNs would fail. The Sun documentation on this patch indicates it clears problems with semaphore -init on systems with large memory. Ever since our system was patched to this level the problems have disappeared. |
|
Back to top |
|
 |
tso0rxp |
Posted: Tue Aug 03, 2004 9:12 am Post subject: |
|
|
 Voyager
Joined: 07 Jan 2002 Posts: 85
|
SunOS vcsmer01 5.8 Generic_117350-02 sun4u sparc SUNW,Sun-Fire-280R
I assume these are all inclusive. Are there kernel parms I should investigate? Here are my current settings...
set shmsys:shminfo_shmmax=4294967295
set shmsys:shminfo_shmmin=1
set shmsys:shminfo_shmem = 1
set shmsys:shminfo_shmmni=2048
set shmsys:shminfo_shmseg=2048
set msgsys:msginfo_msgmni=50
set msgsys:msginfo_msgmap=1026
set msgsys:msginfo_msgtql=40
set msgsys:msginfo_msgseg=1024
set semsys:seminfo_semopm = 100
set semsys:seminfo_semaem = 16384
set semsys:seminfo_semvmx = 32767
set semsys:seminfo_semmni = 1024
set semsys:seminfo_semmap = 1026
set semsys:seminfo_semmns = 16384
set semsys:seminfo_semmsl = 100
set semsys:seminfo_semmnu = 2048
set semsys:seminfo_semume = 256
set semsys:seminfo_sema = 1 _________________ Bob Perry
MQ Administrator |
|
Back to top |
|
 |
PeterPotkay |
Posted: Tue Aug 03, 2004 9:23 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
You don't list the last 2 in the Quick Beginings:
set msgsys:msginfo_msgmax = 4096
set msgsys:msginfo_msgmnb = 4096
Maybe those need to be set? _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
tso0rxp |
Posted: Tue Aug 03, 2004 9:42 am Post subject: |
|
|
 Voyager
Joined: 07 Jan 2002 Posts: 85
|
I will do that. Will this require a recycle of the server by any chance? _________________ Bob Perry
MQ Administrator |
|
Back to top |
|
 |
PeterPotkay |
Posted: Tue Aug 03, 2004 9:43 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
It has been my expirience that yes, a reboot will be required, but that is really a Unix question for a (your) Unix Admin. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
btjo |
Posted: Tue Aug 03, 2004 10:50 am Post subject: |
|
|
Novice
Joined: 07 Jul 2004 Posts: 19
|
Yes. A reboot is mandatory if you change the kernel params. |
|
Back to top |
|
 |
bbburson |
Posted: Tue Aug 03, 2004 11:48 am Post subject: correction |
|
|
Partisan
Joined: 06 Jan 2004 Posts: 378 Location: Nowhere near a queue manager
|
PeterPotkay wrote: |
set msgsys:msginfo_msgmnb = 4096
|
should be:
Code: |
set msgsys:msginfo_msgmnb = 65535 |
There's also the bit in Quick Beginnings about
Code: |
set rlim_fd_cur=1024 |
but that's not likely the problem here. |
|
Back to top |
|
 |
PeterPotkay |
Posted: Tue Aug 03, 2004 2:03 pm Post subject: Re: correction |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
bbburson wrote: |
PeterPotkay wrote: |
set msgsys:msginfo_msgmnb = 4096
|
should be:
Code: |
set msgsys:msginfo_msgmnb = 65535 |
|
Are you looking at the latest version?
From http://publibfp.boulder.ibm.com/epubs/pdf/amqdac06.pdf:
Quote: |
set shmsys:shminfo_shmmax = 4294967295
set shmsys:shminfo_shmseg = 1024
set shmmin:shminfo_shmmin = 1
set shmsys:shminfo_shmmni = 1024
set semsys:seminfo_semmni = 1024
set semsys:seminfo_semaem = 16384
set semsys:seminfo_semvmx = 32767
set semsys:seminfo_semmap = 1026
set semsys:seminfo_semmns = 16384
set semsys:seminfo_semmsl = 100
set semsys:seminfo_semopm = 100
set semsys:seminfo_semmnu = 2048
set semsys:seminfo_semume = 256
set msgsys:msginfo_msgmni = 50
set msgsys:msginfo_msgmap = 1026
set msgsys:msginfo_msgmax = 4096
set msgsys:msginfo_msgmnb = 4096
Figure 1. Setting kernel parameter values on a Solaris system
|
_________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
tso0rxp |
Posted: Wed Aug 04, 2004 3:37 am Post subject: |
|
|
 Voyager
Joined: 07 Jan 2002 Posts: 85
|
If there is nothing obvious to you guys - other than a few kernel settings - I'm going to put a call in to IBM this morning. _________________ Bob Perry
MQ Administrator |
|
Back to top |
|
 |
bbburson |
Posted: Wed Aug 04, 2004 6:44 am Post subject: Re: correction |
|
|
Partisan
Joined: 06 Jan 2004 Posts: 378 Location: Nowhere near a queue manager
|
PeterPotkay wrote: |
Are you looking at the latest version?
|
I thought I was; but I see it has been revised sometime this year. My bad. |
|
Back to top |
|
 |
rammer |
Posted: Wed Aug 11, 2004 5:39 am Post subject: |
|
|
Partisan
Joined: 02 May 2002 Posts: 359 Location: England
|
Hi,
On the theme of process amqzlaao, I have noticed that one of our Developemnt Servers has this continously as the top process's. The Queue Manager is running on HPUX11 MQ5.3 CSD04.
The queue manager is doing very little work, and on duplicate(hopefully) kit in production every thing looks fine.
Can anybody suggest any ways of finding out why this is occurring?
Regards
CPU TTY PID USERNAME PRI NI SIZE RES STATE TIME %WCPU %CPU COMMAND
1 ? 26593 root 152 20 44672K 1348K run 983:59 26.64 26.59 amqzlaa0 |
|
Back to top |
|
 |
|