high MPSYNCH

[groso]

Hi , we are migrating our infrastructure based on Alpha and DMQ 3.2 over
OpenVMS 7.3.2 to Itanium and BMQ 5.0.1 over OpenVMS 8.3-1h1. We are using
automated tests to verify performance in the new environment. When we run these
tests, we found a high MPSYNCH use by the system which makes the processes to hold waiting for cpu.
Any help please ??

[Thomas Ritter]

Groso,
How about posting some number ? How high ? How many cpus do have configured ? What is the typical CPU queue length ?

The DMQ upgrade from 3.2 to 5.01 is major. Make sure your patched up. Are you using decnet or ip for DMQ communications ?

[Paul Jerrom]

Howdy,

Which DMQ V5.01? I am using RP4, there may be newer (I pay HP maintenance dolalrs for MQ but am never told about new releases). There was a problem (!) with the initial V5 MQ when it came out, which caused problems in a cluster (don't know about the MP effects that might have had, if any). There is a new(ish) VMS update available for 8.3 (Update V10) so that might help.
We currently have no MQ related performance issues on our rx2620 cluster.
I did have problems some years ago with an automated test suite, which caused performance issues - problem was the test suite was firing more transactions than a normal load!

Have fun
PJ

[Hein van den Heuvel]

Yeah, please quantify.
Please summarize $MONI MODE output.

Also you indicate the increase MPsync ratio, but did not indicate how the over CPU usage worked out. Is work being done faster?

You fail to indicate hardware models / cpu speeds, but typically an Itanium will do your usermode code faster than the Alpha, but the system time may not improve as much.
So if (UN-typically) the application used 800 seconds in usermode, 150 in kernel and 50 in MPsync (5%) teh same amount of work may now take 400 second user, 125 kernel and 50 MPsync or 10% MPsync... but is woudl be done twice as fast.

Anyway, MPsync time is time 'spinning for based memory locks'.
You can ask the system what it is spinning on using ANAL/SYSTEM and the SPL extention.

The easiest way to get going with that is to use: SYS$EXAMPLES:SPL.COM
Please READ before execute.

From there you should be able to tell whether to focus on memory management, scheduling, locks, whatever.

Good luck,
Hein van den Heuvel
HvdH Performance Consulting

[Guy Peleg]

This is a known problem. The message queue
link driver makes very inefficient use of
ASTs which creates contention
for the SCHED spinlock, which in turn triggers the high MPsync time. If you are
interested in more details please contact me
offline at guy dot peleg AT maklee DOT com

Regards,

Guy Peleg
Maklee Engineering
www.maklee.com