| Author |
Message |
 Topic: Performance questions |
steve_baldwin
Replies: 18
Views: 37971
|
 Forum: General IBM MQ Support Posted: Fri Oct 19, 2001 3:23 pm Subject: Performance questions |
I think our K class is a superseeded version of what is now a L2000. It has 440 MHz CPUs. It looks like it must be purely related to clock speed. Here's my little FP bmark program ...
#include ... |
| Topic: Performance questions |
steve_baldwin
Replies: 18
Views: 37971
|
Forum: General IBM MQ Support Posted: Fri Oct 19, 2001 1:29 pm Subject: Performance questions |
| Apart from moving from MQ 5.1 to 5.2, what conclusions can we draw from this ? Is anyone else out there running MQ on an HP K class ? Can anyone suggest any changes we could look at making to lift t ... |
| Topic: Performance questions |
steve_baldwin
Replies: 18
Views: 37971
|
Forum: General IBM MQ Support Posted: Fri Oct 19, 2001 2:52 am Subject: Performance questions |
You're quite correct about Linux.
For those that are interested, here's the code (basic as it is) ...
/*******************************************************************************
* Modu ... |
| Topic: Performance questions |
steve_baldwin
Replies: 18
Views: 37971
|
Forum: General IBM MQ Support Posted: Thu Oct 18, 2001 2:24 pm Subject: Performance questions |
| The HP machine was certainly not CPU bound. It has a very fast disk subsystem, so, although I don't know for sure, I don't think it was IO bound either. Not sure what that leaves. As far as memory ... |
| Topic: Performance questions |
steve_baldwin
Replies: 18
Views: 37971
|
Forum: General IBM MQ Support Posted: Thu Oct 18, 2001 1:22 pm Subject: Performance questions |
In each case the version of MQ is 5.1, with latest patches. The queue is defined with no persistence, and the MD is also defined with no persistence.
Maybe this is something IBM dont want us to kn ... |
| Topic: Performance questions |
steve_baldwin
Replies: 18
Views: 37971
|
Forum: General IBM MQ Support Posted: Wed Oct 17, 2001 9:38 pm Subject: Performance questions |
Hi there,
I have recently been doing some benchmarking (not terribly scientific) comparing MQ performance on different platforms. The results have surprised me very much, and I'd be interested in ... |
| Topic: signal handling |
steve_baldwin
Replies: 1
Views: 10855
|
Forum: IBM MQ API Support Posted: Tue Oct 02, 2001 11:02 pm Subject: signal handling |
| Actually, I think I've found the reference in the manual that tells me this is the "necessary" behaviour for operating in a threaded environment. Pretty damn ugly IMHO, but I'd still be interested in ... |
| Topic: signal handling |
steve_baldwin
Replies: 1
Views: 10855
|
Forum: IBM MQ API Support Posted: Tue Oct 02, 2001 9:25 pm Subject: signal handling |
| We're using MQ 5.1 on HPUX 11, and I'm finding that once I issue an MQCONN call, I cannot trap signals (eg SIGINT, SIGQUIT). Even if I reissue a sigaction() call, it seems to have no effect. I'm usi ... |
| Topic: Queue Manager startup problems |
steve_baldwin
Replies: 6
Views: 18886
|
Forum: General IBM MQ Support Posted: Tue Oct 02, 2001 1:51 pm Subject: Queue Manager startup problems |
Here's a snippet of one of the many FDC files that were produced a couple of days ago. Interestingly (?) since the reboot, things seem to have quietened down considerably.
Have I included enough i ... |
| Topic: Queue Manager startup problems |
steve_baldwin
Replies: 6
Views: 18886
|
Forum: General IBM MQ Support Posted: Mon Oct 01, 2001 2:00 pm Subject: Queue Manager startup problems |
| One of the things that would be helpful would be if we can control the ownership of shmem segs and semaphores. On the box this happens most frequently on, we have 3 or 4 qmgrs running concurrently, a ... |
| Topic: Queue Manager startup problems |
steve_baldwin
Replies: 6
Views: 18886
|
Forum: General IBM MQ Support Posted: Mon Oct 01, 2001 2:49 am Subject: Queue Manager startup problems |
This is a problem we get from time to time, and I have no idea how to solve it.
On issuing the strmqm {QM Name}, we get the error saying it couldn't start because the following process id's are still ... |
