Itanium vs PA-RISC. Does load numbers compare?

[Fredrik Uddin-Backman2]

Hi

We have an progress database application running on three N4000 machines. This has been running for several years and we know our application fairly well. We know that when our average load goes over 10 it is time to a) add CPU or b) add CPU :-). Now we are in the process of changing hardware to three RX8640 (4 x Montecito). This setup should blow our old setup away and scale up to 2-3 times as many users. But during testing I can sense that we dont get even twice the performance. Also, if our old system is runnable (from users point of view) at a load of 10, our new system is not runnable at a load of 3. This is with the same reference database load. Is the way HP count the load different between Integrity/PA or 11.0/11.23?

[Steven E. Protter]

Shalom,

Impossible to answer on information provided.

Load factor is a bad measure of how much work the system is doing.

The performance can issue can do with several factors:

I/O environment (very often)
Oracle needs run time with stats pack to optimize the data performance.

Just because the CPU is twice as fast does not mean that processing should be twice as fast.

http://www.hpux.ws/system.perf.sh

SEP

[Steve Lewis]

Frederick,

More information is needed. As SEP says, if you are blocked on i/o then it will only go as fast as the i/o. Databases are pretty-much blocking on i/o by definition.
However, the load factor is a good indicator of processes waiting for cpu time.
If you are reducing the number of cpus, then they will be contending for memory and other resources.
There may be spin-lock, shared memory and semaphore coding differences based upon the new cpu architecture, which could impact the load profile.

How many cpus and at what speed were installed in the old system?

Steve

[Patrick Wallek]

Are you running an IA version of Progress or are you running a PA-RISC version through the Aries emulator?

If running PA-RISC through Aries, then that could slow you down.

[Fredrik Uddin-Backman2]

I believe that I/O is not the problem here. sar -d gives:
Average c0t6d0 4.47 10.70 15 405 11.28 12.42
Average c2t6d0 3.55 11.98 13 396 12.45 11.35
Average c8t0d2 0.16 0.50 0 4 0.00 7.39
Average c14t0d2 0.14 0.50 0 4 0.00 6.92
Average c8t1d1 0.02 0.50 0 1 0.00 0.45
Average c8t0d3 0.22 0.50 0 5 0.00 9.85
Average c7t0d2 0.05 0.50 0 1 0.00 5.20
Average c13t1d1 0.02 0.50 0 1 0.00 0.58
Average c14t0d3 0.22 0.50 0 5 0.00 9.86
Average c13t0d4 0.03 0.50 0 1 0.00 6.45
Average c10t1d1 0.03 0.50 0 1 0.00 0.83
Average c7t1d1 0.02 0.50 0 1 0.00 0.56
Average c14t1d1 0.02 0.50 0 1 0.00 0.48
Average c4t0d3 0.04 0.50 0 3 0.00 1.98
Average c5t0d4 0.19 0.50 0 7 0.00 6.74
Average c11t0d4 0.16 0.50 0 7 0.00 5.92
Average c8t0d4 0.27 0.50 0 7 0.00 10.21
Average c14t0d4 0.25 0.50 0 6 0.00 10.26
Average c4t0d1 0.14 0.50 0 4 0.00 7.94
Average c10t0d1 0.13 0.50 0 4 0.00 8.16
Average c8t0d1 0.11 0.50 0 3 0.00 7.50
Average c14t0d1 0.11 0.50 0 3 0.00 8.43
Average c4t0d2 0.09 0.50 0 3 0.00 4.17
Average c10t0d2 0.10 0.50 0 4 0.00 3.94
Average c13t0d2 0.04 0.50 0 1 0.00 5.31
Average c10t0d3 0.04 0.50 0 3 0.00 2.43
Average c4t1d1 0.03 0.50 0 2 0.00 0.83
Average c5t1d1 0.03 0.50 0 1 0.00 0.72
Average c7t0d3 0.03 0.50 0 1 0.00 7.01
Average c5t0d2 0.03 0.50 0 1 0.00 4.00
Average c7t0d4 0.03 0.50 0 1 0.00 5.71
Average c11t1d1 0.03 0.50 0 1 0.00 0.54
Average c4t0d4 0.02 0.50 0 1 0.01 7.15
Average c7t0d1 0.02 0.50 0 0 0.00 6.29
Average c11t0d2 0.03 0.50 0 1 0.00 3.29
Average c11t0d1 0.02 0.50 0 0 0.00 7.21
Average c10t0d4 0.02 0.50 0 0 0.00 7.11
Average c13t0d3 0.01 0.50 0 0 0.00 2.51
Average c5t0d3 0.01 0.50 0 0 0.00 6.31
Average c13t0d1 0.01 0.50 0 0 0.00 4.45
Average c10t1d3 0.00 0.50 0 0 0.00 0.13
Average c5t0d1 0.02 0.50 0 0 0.00 7.62
Average c11t1d5 0.00 0.50 0 0 0.00 0.23
Average c11t0d3 0.01 0.50 0 0 0.00 4.50
Average c10t1d2 0.00 0.50 0 0 0.00 0.38
Average c10t1d4 0.00 0.50 0 0 0.00 0.30
Average c5t1d5 0.00 0.50 0 0 0.00 0.28

This devices is spread over two EVA8K, each with 32 300GB 10k rpm disks.

[Fredrik Uddin-Backman2]

We are running Openedge 10.1B IA64 version

[Hein van den Heuvel]

What does the user:system time picture look like? Similar system time usage on the Itanium, or much more?

WAG: The application may have been tolerating alignment faults and they became more expensive to deal with under Itanium.
See blurb below for a few details.
Of course that would be a serious problem for you, as that would be progress code.

So was progress porteed or running under Aries? That could easily explaining dissapointing Pa - ipf scaling.

fwiw,
Hein.

"Applications can
enable default handling of alignment fixups by linking against an additional
library: libunalign on Itanium®-based systems and libhppa.a on
PA-RISC systems. Additionally they must enable the handler by calling
allow_unaligned_data_access( ). Note that for threaded applications on
Itanium®-based systems, allow_unaligned_data_access( ) must be called
within each thread in order to handle unaligned accesses generated by the thread.
On PA-RISC systems, it is sufficient to call allow_unaligned_data_access( )
just once from the main program. More information on the handling of unaligned
data is available in the HP aC++ Programmerâ s Guide available at:
http://docs.hp.com/en/dev.html
"

[Fredrik Uddin-Backman2]

Progress version is native IA64

[Dennis Handly]

>Hein: The application may have been tolerating alignment faults and they became more expensive to deal with under Itanium.

No, IPF is 10 to 100 times faster than PA in handling alignment faults. Either the hardware handles it directly, or the kernel handler is much faster.