| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Solaris Kernel Configuration |
« View previous topic :: View next topic » |
| Author |
Message
|
| bduncan |
 Posted: Wed Apr 18, 2001 9:18 am Post subject: |
 |
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
A lot of people in the past have run into this problem, namely, the kernel configuration on solaris is not sufficient to run MQSeries. Add the following values to the /etc/system file and be sure to reboot. Make sure you do all of this before creating a queue manager on the box.
/etc/system
set shmsys:shminfo_shmmax = 4294967295
set shmsys:shminfo_shmseg = 1024
set shmsys:shminfo_shmmni = 1024
set semsys:seminfo_semaem = 16384
set shmsys:shminfo_semmni = 1024
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_msgmap = 1026
set msgsys:msginfo_msgmax = 4096
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
 |
| NeilCasey |
| Posted: Mon Jun 25, 2001 9:43 pm Post subject: |
|
|
Newbie
Joined: 24 Jun 2001
Posts: 4
|
The recommendation on /etc/system is in the Quick Start guide, but is critical, and worth reiterating. However, the values given are suitable for one queue manager which is not too busy. In environments with multiple queue managers, or where queue managers are busy, you may need to increase these values. IBM has not been able to provide good guidelines (to my knowledge) on how to tune these values. The manual also completely leaves out any mention of two importamt parameters.
set rlim_fd_max = 1024
set rlim_fd_cur = 1024
Prior to solaris 2.7, the maximum values for these was 1024. It is now maxint at 2.7 and above. IBM has records on IBMLink referencing these parameters as fixes to various reported problems, but they don't seem to have made it into the manuals yet.
The other thing to note is that the values listed allow for MQSeries usage of shared memory and semaphores, but if you have other users of these resources (such as BMC Patrol) then these values may not be sufficient.
Neil Casey. |
|
| Back to top |
|
|
| bduncan |
| Posted: Tue Jun 26, 2001 8:22 pm Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Neil,
thanks for the additional info. The point you made about other services using these same resources is important, because some products, require even more of these resources than MQSeries. For instance, on one sun ultra we had, we were running MQSeries without a problem (after updating /etc/system according to the quick beginnings guide) and then installed Oracle and everything broke. Turns out that Oracle needs even more of certain resources than MQSeries, so we had to go back and increase values in /etc/system beyond what we required for MQSeries...
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| Cliff |
| Posted: Fri Jun 29, 2001 4:50 am Post subject: |
|
|
Centurion
Joined: 27 Jun 2001
Posts: 145
Location: Wiltshire
|
This might help - it's from IBM:
Solaris Kernel Parameters for MQ
MQSeries makes extensive use of IPC (Inter-Process Communication) resources,
including shared memory, semaphores, and message queues (the IPC kind). Many
Solaris systems will require some adjustment of the kernel parameters which
govern these resources in order to able to run MQSeries comfortably, or to
support heavily-used MQSeries installations. Indications that MQSeries lacks
enough IPC resources may be an inability to start MQSeries, or difficulty in
running many MQSeries programs concurrently. Furthermore, MQSeries may
generate FDC files in /var/mqm/errors which contain error messages from
IPC-related functions like semget, shmget, or shmat.
In order to make more IPC resources available to MQSeries, it is necessary
to modify the kernel parameters on your machine using facilities like
configure and idtune. Use the values given in this note in preference over
those listed in the MQSeries Quick Beginnings for Solaris book. In cases
where this note mentions new parameters, or overlooks some listed in the
Quick Beginnings book, again give preference to this note. For more
information on modifying your kernel, refer to your Solaris documentation or
contact Solaris support.
We strongly urge you to save your current kernel configuration before trying
to make any changes. When you make changes, realize that other programs
(databases, for example) which make much use of IPC resources may force you
to modify these parameters so that both MQSeries and those programs will
run. The values msgmax, msgmnb, msgssz, semaem, semume, semvmx, shmmax, and
shmseg should not in general require augmentation if you are running
databases or other IPC-intensive programs. The values msgmap, msgmni,
msgseg, msgtql, semmap, semmni, semmns, semmnu, and shmmni may require
augmentation depending on the other programs running on the system. Refer to
the meaning of each parameter listed below and other vendors' instructions
to help you with that determination.
In general, the values that follow are only policing values. In other words,
they can usually be over-allocated without causing harm to your system. This
means that if your existing programs are not already running up against the
limits you have specified, they will not use more kernel resources after
modifying your kernel parameters.
Note: The parameters for Shared Memory and Semaphores tend to be more
important than the parameters for Message Queues.
Note: The correct way of getting kernel parameters on a Solaris box is with
the
following command...
/usr/sbin/sysdef -i > kernel.txt
Please do not ask for the /etc/system file from customers to get kernel
parameters. This file is used to set/tune kernel parameters and the
parameters in this file will not be picked up until the box is rebooted. So
getting the /etc/system file from the customer box might not give you the
correct information as to what kernel parameters the operating system is
actually running with.
These are the recommended MINIMUM parameters...
________________________________________________________
IPC Message Queue Parameters
_____________________________________________
mesg 1 This should not be changed, and is generally hard-coded.
msgmap 1026 This is the number of entries in the kernel's
message map table. This value should equal msgtql+2, and is should always be
less than msgseg. A value roughly half of msgseg should be good.
msgmax 4096 This is the maximum size of a single message in bytes.
msgmnb 4096 This is the maximum number of bytes that all the
messages on a single message queue can occupy.
msgmni 50 This is the maximum number of message queues
allowed on the system at any time.
msgseg 2048 This is the number of memory segments allocated
by the kernel at system startup to hold messages. Each system will have a
limit on the total memory allocated (msgseg*msgssz), often 128KB.
msgssz 8 This is the size in bytes of the memory segments
used for storing messages. Valid values must
be multiples of 4.
msgtql 1024 This is the number of system messages headers
which the kernel can store, which is effectively
the maximum number of unread messages at any time.
_____________________________________________
IPC Semaphore Parameters
_____________________________________________
sema 1 This should not be changed, and is generally hard-coded.
semaem 16384 This is the maximum adjust-on-exit value for a
semaphore. It must be less than or equal to semvmx.
semmap 1026 This is the size of the kernel's map of
semaphore sets. This value should equal but never exceed semmni+2.
semmni 1024 This is the maximum number of semaphore sets
that can exist on the system at any time.
HP-UX hard-codes the number of semaphores per
set (semmsl on Solaris systems) to 500, so if
only "full" semaphore sets are going to be
allocated, this value should be roughly
semmns/500. MQSeries generally allocates 64
semaphores per set, so if most of the
semaphore usage on the system is due to
MQSeries, a more ideal number would be semmns/64.
semmns 32767 This is the maximum number of semaphores in
the system. A value of 16384 will generally work for a small MQSeries
installation, but setting it to 32767 is advisable for larger systems.
semmnu 2048 This is the number of semaphore undo
structures allocated by the system. It must be less than or equal to
nproc-4.
semmsl 128 This is the maximum number of semaphores per
semaphore set
semopm 128 This is the maximum number of semaphore
operations that can be done by one semop() call. If this is set to semmsl,
one semop() call can operate on every semaphore in a semaphore set, although
MQSeries does not require this.
semume 256 This is the number of semaphore undo entries
for each process.
semvmx 32767 This is the maximum value that a semaphore can have.
_____________________________________________
IPC Shared Memory Parameters
_____________________________________________
shmem 1 This should not be changed, and is generally
hard-coded.
shmmax 4194304 This is the maximum size in bytes of a shared
memory segment.
shmmni 1024 This is the maximum number of shared memory
segments that can exist on the system at any time. 1024 is the maximum on
many systems.
shmseg 1024 This is the maximum number of shared memory
segments that a single process can have at any time. It should always be
less than or equal to shmmni.
_____________________________________________
Miscellaneous Parameters
____________________________________________
maxusers 32 This controls the number of users which can
log in to the system. More importantly, it
controls other system values which limit the
number of processes that can run at once.
...
Rather than changing maxusers, we would recommend that you alter the nproc
and maxuprc values as follows:
nproc: The maximum number of processes on the system.
1 for each non-MQSeries process on the system PLUS
3 for each MQSeries queue manager (strmqm) PLUS
2 for each MQSeries receiver or svrconn channel PLUS 1 for each MQSeries
sender channel PLUS 1 for each other MQSeries process (runmqtrm, etc.)
maxuprc: The maximum number of processes for a single user.
1 for each non-MQSeries process run by 'mqm' PLUS 3 for each MQSeries queue
manager (strmqm) PLUS 2 for each MQSeries receiver or svrconn channel
PLUS 1 for each MQSeries sender channel PLUS 1 for each other MQSeries
process (runmqtrm, etc.)
Users of Sun Solaris 2.5.1 or better may wish to verify that they are not in
fact using more than 25% of their kernel resources for semaphore structures.
In order to calculate this in bytes, use the formula given below. Also, if
you are letting the kernel determine nproc for you, you can find this value
by typing 'sysdef | grep v_proc':
kernel_memory = semmns * 16 +
nproc * 16 +
semmni * 92 +
semmnu * ((semume + 1) * 16) * 4
Solaris 2.5.1 users must also be certain that they are not using more than
25% of their kernel resources for shared memory structures. In order to
calculate this in bytes, use the formula given below:
kernel_memory = shmmni * 120
Of course, simply calculating the bytes needed for shared memory and
semaphore structures is not terribly useful if you don't know what the
overall kernel resources are. Kernel memory is limited by your kernel
architecture as well as by your available RAM. Type 'uname -m' to see what
your kernel architecture is. The maximum kernel memory that common Sun
architectures can use today is given below:
Kernel Resources Machines
Sun4m 256 MB ------
Sun4d 576 MB SS1000, SC2000
Sun4u 4 GB UltraSPARC
|
|
| Back to top |
|
|
| dgolding |
| Posted: Wed Jul 04, 2001 1:35 am Post subject: |
|
|
Yatiri
Joined: 16 May 2001
Posts: 668
Location: Switzerland
|
| Just a minor thing - BMC Patrol does not use IPCS stuff DIRECTLY - it consumes IPC resources via. the MMA clients it uses to communicate with MQ. |
|
| Back to top |
|
|
| @.@ |
| Posted: Thu Jul 05, 2001 7:15 pm Post subject: |
|
|
Newbie
Joined: 04 Jul 2001
Posts: 1
Location: Hong Kong
|
|
| Back to top |
|
|
| andystone |
| Posted: Fri Aug 02, 2002 8:26 am Post subject: |
|
|
Newbie
Joined: 18 Jun 2002
Posts: 8
Location: Surrey, UK
|
| excuse my ignorance, but I presume the recommended kernel settings are only for MQSeries Server, and not applicable to Client only installation? |
|
| Back to top |
|
|
| jconway |
| Posted: Mon Apr 28, 2003 2:59 am Post subject: |
|
|
Novice
Joined: 28 Apr 2003
Posts: 17
Location: Paris, France
|
Excuse my ignorance as well but I'd love to have "andystone"'s previous point clarified if possible. It's not stated clearly in any of the IBM documentation whether it's necessary to alter kernel parameters when performing a Client-only installation on Solaris ... in fact the documentation gives the impression that these kernel changes are associated with the Server installation only. However when installing the Client product on Sloaris I received the following :
===============================================
Checking kernel configuration...
33554432 max shared memory segment size (SHMMAX)
24 max attached shm segments per process (SHMSEG)
100 shared memory identifiers (SHMMNI)
300 semaphore identifiers (SEMMNI)
300 semaphores in system (SEMMNS)
25 max semaphores per id (SEMMSL)
10 max operations per semop call (SEMOPM)
600 undo structures in system (SEMMNU)
10 max undo entries per process (SEMUME)
2048 max message size (MSGMAX)
ADVISORY WARNING - You may need to alter the kernel parameters listed above to run WebSphere MQ. See the Quick Beginnings manual for more information.
===============================================
Does anyone have a definite yes or no response to this query?
In addition, this is my first posting. I'd like to say that I've found this site to be of invaluable assistance over the past 3 months as I've begun to explore the world of MQ. |
|
| Back to top |
|
|
| cute_pav |
| Posted: Fri May 23, 2003 8:29 am Post subject: |
|
|
Acolyte
Joined: 04 Jan 2002
Posts: 65
Location: usa
|
Hi, all,
thanks for all your input.
Hi, niel,
I could n't see these values in my sysdef file.Where I could find these values?.
set rlim_fd_max = 1024
set rlim_fd_cur = 1024
pavan |
|
| Back to top |
|
|
| dgolding |
| Posted: Mon May 26, 2003 12:56 am Post subject: |
|
|
Yatiri
Joined: 16 May 2001
Posts: 668
Location: Switzerland
|
Hi,
Sysdef is the utility to display the system settings. You should put the rlim_fd parameters in the file /etc/system .
For some reason sysdef doesn't display these params, but if use ulimit -a you should see:
nofiles(descriptors) 1024
HTH |
|
| Back to top |
|
|
| jconway |
| Posted: Mon Oct 06, 2003 5:46 am Post subject: |
|
|
Novice
Joined: 28 Apr 2003
Posts: 17
Location: Paris, France
|
Just an update regarding my previously posted question.
The answer is, that you must change the kernel parameters only if you
install a MQ Server. If you install a MQ Client you can ignore the message
that you should change the kernel configuration.
Many thanks to Carsten Scheunemann for emailing me this information which he received from IBM support. |
|
| Back to top |
|
|
| mjgurney |
| Posted: Tue Aug 10, 2004 3:23 am Post subject: |
|
|
Novice
Joined: 17 May 2004
Posts: 15
Location: UK, London
|
|
| Back to top |
|
|
| JAKEZ |
| Posted: Mon Oct 18, 2004 11:19 pm Post subject: |
|
|
Apprentice
Joined: 03 Oct 2002
Posts: 32
|
Hi Cliff - this reply for you:
- you said about 'Solaris Kernel Parameters for MQ ':
"it's from IBM: "
- is it an official answer from IBM support or some information documented somewhere?
thanks in advance
Jakez  |
|
| 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
|
|
|
|
