Dubtes performance
- com saber sin un qmgr en execució te "LogWriteIntegrity=SingleWrite" o "LogWriteIntegrity=TripleWrite" ?
| home / infca / mq_perf (navigation links) | His epitaph reads "All Right Now" |
QM LOG
QM channels
QM listeners
QM buffer sizes
Each queue in the queue manager is assigned two buffers to hold messages, one for non-persistent messages and one for persistent messages. The non-persistent queue buffer size is specified using the tuning parameter DefaultQBufferSize. The persistent queue buffer size is specified using the tuning parameter DefaultPQBufferSize.
Dunn@developerWorks[***]
You are recommended to run channels and listeners as trusted only in a stable environment in which you are not, for example, testing applications or user exits that may abend or need to be cancelled. An errant application could compromise the integrity of your queue manager. However, if your environment is stable and if performance is an important issue, you may choose to run channels and listeners as trusted.
MQ v6.0 intercommunication, "Running channels and listeners as trusted applications", pg 129.
Queue Manager performance tuning is probably one of the most important things to get right when using WebSphere MQ. Sometimes it is not easy to figure out what settings would work best for your install. In this post I will take you through some of the performance settings you can use when creating your queue managers.
The options that I typically use for a performance setup are:
Typically I will set -h 50000 which is more than my tests need, but ensures that I am not constrained to the 256 default.
Using circular logging is advised, but be warned that long running transactions that span multiple log files can cause performance degradation to occur.
The default log size is set at 1024 units of 4KB, which works out at 4MB of log.
I typically set -lf 16384 which gives me a log file size of 64MB, big enough for my performance stress tests.
-lp has a default of 3; again I increase this to be 16, giving me 16 log files, each 64MB in size.
The above give us a queue manager that can handle all the clients that I am going to throw at it, allows a large amount of space for persistent messages in the log files. Once the queue manager is created, we can edit parameters within the qm.ini (or Windows Registry) to get actual performance gains over a default installation.
There are a couple of values you can add to the TuningParameter stanza of the qm.ini file,
DefaultQBufferSize and DefaultPQBufferSize.
The default for nonpersistent queue buffer size (DefaultQBufferSize) is 64K per queue.
The maximum that you can set this value is to 100MB,
although I strongly advise you to make sure that you have enough real memory,
as each queue would have 100MB of real memory (which could crash your machine).
For my performance measurements we use a much more realistic 1MB per queue,
which provides us with ample space for our performance tests.
Just to reiterate that setting this value in the qm.ini will affect each queue,
make sure you have enough memory for the value you are setting!
The changes in the qm.ini will only take effect after a queue manager restart.
The setting for a persistent messaging buffer called DefaultPQBuffer size works in exactly the same way :
your messages are still copied to a log,
but if they are requested by a client and are still in the buffer
then they will be read from there, rather then re-read from the logs.
They call it "messaging mode" if there is no "read" involved in the "get()", or "queuing mode" if there is a "read"
In the Channels stanza of qm.ini MQIBindType can be set to MQIBindType=FASTPATH which I understand from a technical perspective means that the channel processes are no longer separate from the queue manager processes. From a performance perspective I categorically know that this gives significant savings of CPU and memory resources compared to the default. The downside of this is that User Exits could corrupt the queue manager memory (if used), and it is also harder to diagnose problems with the channels. But from a pure performance perspective, this is a good option.
No doubt there are other parameters that we could use, increasing the number of channels, increase the number of maximum active channels, but the above parameters are the key ones that give my performance tests a big boost over the default settings when using JMS Client applications.
Is there any way to check the real size of the queue buffer ? qtune does this - está en el supportpac MS0P - nacho
QTune changes the settings on existing queues, and therefore can be used against the SYSTEM.CLUSTER.TRANSMIT.QUEUE, which cannot normally be deleted and recreated.
Dumping the Match Space :
To check the value of the current buffer size use this procedure:
MQ Performance Monitor lets you collect and analyze performance data for queues, channels, and MQI calls for queue managers. System administrators can use WebSphere MQ Explorer itself to monitor the system status of WebSphere MQ for short periods. MQ Performance Monitor provides short-term trend analysis in MQ Explorer for:
Steps :
MQ Performance Monitor contains the following two components:
|
|
|
Updated 20150427
|
|