How I can read the MQ logs to check if messages are persistent or not

steve

For disk, you might want to use a free tool like IOMeter simply to provide some rough benchmarks on what speed your disks are capable of reading/writing at… Particularly with disk IO on windows, look at avg read|writes/sec, avg. disk sec/read|write, disk queue length and also avg disk bytes reads|writes/sec.. Post back your results here if you’re keen.

Now assuming you can’t change your disk subsytem to a faster array, the following recommendations are what I’d suggest in getting the most out of persistent messages:.

1. Since you’re aiming to write 1,000 x 3KB + 750B per message per second, you’re looking at something between 3.5 – 4 MB/sec. This may be close to your disk subsystem limits depending on what that actually is. For example, on a beefed up SAN I’ve clocked over 40MB/sec, however on a clients production web server with a SATA RAID 5 array, they could only get 6MB/sec. On my Mac VM I can only get 2MB/sec So it really is important to balance the theoretical performance of your subsystems before going nuts with tuning parameters…

2. Having said all that though, you have increased the LogFilePages=16384 which will make your individual log files bigger (approx 64MB). This will cut down on the rate MQ needs to open close files under load. I’ve seen this have a significant impact on performance. You should check date time stamps on these log files to see how quickly MQ is circling through those . I imagine at a target rate of 4MB/sec, you are probably cycling through at a rate of 1 log file every 16 seconds

3.I wasn’t aware you could use 4096 for LogBufferPages (I thought max was 512) ie. 512×4 = 2MB buffer max. So maybe just double check that setting is valid.

4. Have you tried the following tuning parameters?
DefaultQBufferSize=1048576
DefaultPQBufferSize=1048576

These may have an impact although can’t comment on their effectiveness.

At the end though, you need to establish if it IS a disk performance bottleneck as you might expect. For what it’s worth, in the past I have run many different tests/configurations on clients systems regarding MQ persistence performance and have found that you can get very high rates.

To illustrate, on a particular client’s subsytem I was getting 1,500 trans/sec for a single thread message producer using messgae persistence (around 300B per messsage). Simply by increasing concurrency, at around 30 threads we were able to double that throughput (it wasn’t necessarily SAN performance as we first thought, although we established that one thread had its maximums for other reasons). In the same environment, we also wrote to a SCSI disk and RAM (just for comparison) with a single thread, and got 300 trans/sec and 3,000+ trans/sec respectively. So no denying disk subsystem configuration has a huge effect on overall performance. Sometimes you can work around this with higher levels of concurrency.

Hope that helps. Regards,
Tim Koopmans

Any tweak thoughts would be helpful.

Essentially, if I truss the MQ queue manager pid whilst under load (with persistence) it will produce this sort of output

truss –D –p 0.0002 write(3, " A A A A A A A A A A A A".., 8192) = 8192
0.0001 write(3, " A A A A A A A A A A A A".., 8192) = 8192
0.0002 write(3, " A A A A A A A A A A A A".., 8192) = 8192
0.0001 write(3, " A A A A A A A A A A A A".., 8192) = 8192
0.0001 write(3, " A A A A A A A A A A A A".., 8192) = 8192
0.0001 write(3, " A A A A A A A A A A A A".., 8192) = 8192
0.0001 write(3, " A A A A A A A A A A A A".., 8192) = 8192
0.0001 write(3, " A A A A A A A A A A A A".., 8192) = 8192
0.0001 write(3, " A A A A A A A A A A A A".., 8192) = 8192
0.0002 write(3, " A A A A A A A A A A A A".., 8192) = 8192
0.0001 write(3, " A A A A A A A A A A A A".., 8192) = 8192

But you do need root access. The 8KB observed above was from my own perl script which aims to simulate the effect of MQ persistence on a disk subsystem, without having to install MQ in the first place …