strange behavior with readprobe

trollnba

New Member
Hello,

One of my Russian customer is doing a Progress DB test using readprobe tool. To do so, he's using remotely in France an IBM P570 power6 with AIX 5.3 (TL6 SP3). the results we have are quite disturbing.
With a partition configured with 4 dedicated cpus (SMT is off), we're reaching the maximum rec/s (411000) with 4 _progress processes. OK. That's normal if I believe the graphs I've seen on Tom Bascom site (the max perf occurs with number of _progres processes = number of cpus).
When we add two more cpus (so we have now 6 cpus) and do the same test, the maximum is now with 6 processes (still normal), but we're reaching a little bit less than 410000 rec/s. so with 6 cpus and 6 processes, we're doing less perf than with 4 cpus and 4 processes. Strange !
Much stranger : With a 6 cpu lpar, when running 4 processes, I thought we should have had the same perf than on a 4 cpu lpar with 4 processes as in both case we're really consumming 4 cpus (In the second case, we have 2 cpus doing nothing). But no : 6 cpus available and 4 processes, we're reaching only 309000 rec/s, so 25% less than with 4 cpus available and 4 processes.

Any ideas ?
 

TomBascom

Curmudgeon
What version of Progress?

What do you mean by "(SMT is off)"?

There are many odd behaviors that pop up under the conditions that readprobe creates. That's sort of the point ;) You're finding exactly the sort of thing that readprobe is designed to help you find. Far better to find them now then to find them when you go into production...

Readprobe stresses Progress latch mechanism and indirectly stresses the hardware and the OS at a fairly low level and in some ways that might be expected to reveal issues like "an LPAR isn't quite the same as a naked machine" or "more CPUs aren't always better".
 

trollnba

New Member
version of progress : 10.1B

SMT is the Simultaneous Multi-Threading. When it's on, you can run two threads simultaneously (really, so better than the Hyperthreading :awink:) onto one core. Doing so, when you have 4 physical cpu with SMT ON, your application sees 8 logical cpus.
But here SMT is off, so only one thread per core.
 

TomBascom

Curmudgeon
version of progress : 10.1B

Which patch?

If you have not already done so try getting the latest patch. I know that the sort of thing that you're seeing has been a a topic of interest of late.

SMT is the Simultaneous Multi-Threading. When it's on, you can run two threads simultaneously (really, so better than the Hyperthreading :awink:) onto one core. Doing so, when you have 4 physical cpu with SMT ON, your application sees 8 logical cpus.
But here SMT is off, so only one thread per core.

Ah! Thanks.
 

trollnba

New Member
10.1B02, patch 02. The customer is telling me it's the last level. Correct ?

We've done some analyses and it seems that the progress latch mechanism is not scaling well. When going from 4 cpu to 6 cpu, with 4 _progress processes (so we're supposed to do the same thing in both case), several latch functions are taking more cpu time:
latObjLatchLocklatlatchlatXlockbmLocateBuffer2latObjLatchFree

For example the last one latObjLatchFree is taking twice the cpu time with 6 cpu than with only 4.

Is it ringing a bell to you ? What do you think ?
Thanks in advance.
 

TomBascom

Curmudgeon
SP03 was released on 11/15.

In any event, yes, this sounds quite familiar. You (or your customer) should get in touch with tech support and the engine crew. Actually I suspect your customer already has...
 
Top