| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| mqseries 5.2 fails on crtmqm with shmat error |
« View previous topic :: View next topic » |
| Author |
Message
|
| lwessels |
 Posted: Mon Sep 24, 2001 2:05 am Post subject: |
 |
|
Newbie
Joined: 23 Sep 2001
Posts: 4
|
Hi,
We have a problem with MQSeries 5.2 on SUN Solaris 2.6.
After installing MQSeries (which went perfectly), we get an error when creating a queue manager with the "crtmqm" command.
The error is "too many open files from shmat". Probably has to do something with the SUN kernel parameters. We also have Oracle8 on this machine.
Has anyone an idea what actions we should take?
Thanks very much
Leo Wessels
|
|
| Back to top |
|
 |
| kolban |
| Posted: Mon Sep 24, 2001 6:11 am Post subject: |
|
|
Grand Master
Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA
|
|
| Back to top |
|
|
| lwessels |
| Posted: Mon Sep 24, 2001 6:34 am Post subject: |
|
|
Newbie
Joined: 23 Sep 2001
Posts: 4
|
Hi kolban, thanks for your reply.
Yes, we have changed all parameters according to the specifications. It looks like these specs are not enough on our machine, maybe because Oracle is installed too. We are not sure which parameters we should change.
Maybe somebody has an idea....
Thanks,
Leo |
|
| Back to top |
|
|
| bduncan |
| Posted: Mon Sep 24, 2001 6:54 am Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
I did this once before too, where we needed to install Oracle and MQSeries on the same Solaris machine. I just followed a few basic premises, and everything worked just fine:
1. For any kernel parameters listed by Oracle but not MQSeries, I simply set the values dictated by Oracle
2. For any kernel parameters listed by MQSeries, but not Oracle, I set them to the values listed in the MQSeries Solaris Quick Beginnings Guide
3. When a parameter was listed by both programs, I took the sum of the two values recommended by MQSeries and Oracle. If this sum was greater than the hard-limit, I set it to the hard-limit.
This seemed to work for me. Of course, both the Oracle and MQSeries documentation say that the kernel parameters they specify are for instances of their product under light to moderate loads. If either or both of these products are expected to be used under heavy load, I would further increase these values.
As an example you may find useful, here are the kernel parameters for a machine that has been tweaked quite a bit, and because of the very heavy loads it handles, the kernel parameters are very high:
*
*
*-----------------------------------------------------------------------------
*Changing the file descripters for the system
*-----------------------------------------------------------------------------
set rlim_fd_cur=4096
set rlim_fd_max=4096
*-----------------------------------------------------------------------------
* S E M A P H O R E S
*-----------------------------------------------------------------------------
*semsys:seminfo_semmap default=10 Number of entries in the semaphore map
*-----------------------------------------------------------------------------
set semsys:seminfo_semmap=8194
*-----------------------------------------------------------------------------
*semsys:seminfo_semmni default=10 Number of semaphore identifiers
*-----------------------------------------------------------------------------
set semsys:seminfo_semmni=8192
*-----------------------------------------------------------------------------
*semsys:seminfo_semmns default=60 Number of semaphores in the system
*-----------------------------------------------------------------------------
set semsys:seminfo_semmns=32768
*-----------------------------------------------------------------------------
*semsys:seminfo_semmnu default=30 Number of undo structures in the system
*-----------------------------------------------------------------------------
set semsys:seminfo_semmnu=4096
*-----------------------------------------------------------------------------
*semsys:seminfo_semmsl default=25 Maximum number of semaphores, per id
*-----------------------------------------------------------------------------
set semsys:seminfo_semmsl=200
*-----------------------------------------------------------------------------
*semsys:seminfo_semopm default=10 Maximum number of operations, per
* semaphore call
*-----------------------------------------------------------------------------
set semsys:seminfo_semopm=128
*-----------------------------------------------------------------------------
*semsys:seminfo_semume default=10 Maximum number of undo entries,
* per process
*-----------------------------------------------------------------------------
set semsys:seminfo_semume=128
*-----------------------------------------------------------------------------
*semsys:seminfo_semvmx default=32767 Semaphore maximum value
*-----------------------------------------------------------------------------
set semsys:seminfo_semvmx=64535
*-----------------------------------------------------------------------------
*semsys:seminfo_semaem default=16384 Maximum value for adjustment on exit
*-----------------------------------------------------------------------------
set semsys:seminfo_semaem=32767
*-----------------------------------------------------------------------------
* S H A R E D M E M O R Y
*-----------------------------------------------------------------------------
*shmsys:shminfo_shmmax default=1048576 Maximum shared memory segment size
*-----------------------------------------------------------------------------
set shmsys:shminfo_shmmax=537133056
*-----------------------------------------------------------------------------
*shmsys:shminfo_shmmin default=1 Minimum shared memory segment size
*-----------------------------------------------------------------------------
*set shmsys:shminfo_shmmin=200
*-----------------------------------------------------------------------------
*shmsys:shminfo_shmmni default=100 Number of shared memory identiers
*-----------------------------------------------------------------------------
set shmsys:shminfo_shmmni=1024
*-----------------------------------------------------------------------------
*shmsys:shminfo_shmseg default=6 Segments, per process
*-----------------------------------------------------------------------------
set shmsys:shminfo_shmseg=1024
*-----------------------------------------------------------------------------
* IPC Message Queue Tunables
*-----------------------------------------------------------------------------
set msgsys:msginfo_msgmnb=4194304
set msgsys:msginfo_msgmax=1048576
set msgsys:msginfo_msgmni=2604
set msgsys:msginfo_msgmap=2048
set msgsys:msginfo_msgssz=256
set msgsys:msginfo_msgtql=3204
set msgsys:msginfo_msgseg=205056
set maxphys = 8388608
Hope this helps....
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| lwessels |
| Posted: Tue Sep 25, 2001 11:59 am Post subject: |
|
|
Newbie
Joined: 23 Sep 2001
Posts: 4
|
Hi Brandon,
Thanks for your very clear reply. We are still in the middle of trying all kinds of settings. We keep crashing during "crtmqm" on the "too many file descriptors open from shamt". The routine is something like xslCreateExtend.
When changing our parameters too the settings you mentined, the process went idle and didn't respond. No crash either  .
My guess is we need to be somewhere in the middle, so we keep tuning.
Is their something we might overlook that is not tied to these kernel settings?
Thanks again. And what a perfect forum this is!
Leo |
|
| Back to top |
|
|
| Kotten |
| Posted: Fri Sep 28, 2001 4:48 am Post subject: |
|
|
Newbie
Joined: 22 Jul 2001
Posts: 2
|
I am not quite sure but I think I had the same problem installing on Solaris 8. E-fix 723 solved that one in any case.
efix: 723
MQ: v5.2 for Solaris
CSD: none
Date: 17 Jan 2001
Description: semctl() call removed from zslEnqueue
Kotten |
|
| Back to top |
|
|
| lwessels |
| Posted: Fri Sep 28, 2001 4:56 am Post subject: |
|
|
Newbie
Joined: 23 Sep 2001
Posts: 4
|
Thanks everybody.
We located the setting that was responsible for the crash. It indeed was one of those kernel parameters: shmsys:shminfo_shmseg. We raised it to 1024 (as suggested in the Quick Beginnings). But somewhere in the etc/system file was a typo which made the reboot not effective on that setting.
Again, thanks for helping us out!
Leo |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
