uncompress is slow for itanium server

[kenken_3]

Hi,

We are tring to uncompress a file on my HPUX11.23 Itanium server (rx8640) and it's size is about 15G. it is quite slow.

I tried to uncompress it on another pa-risc server (rp8440) hpux11.11 and it is much faster. the number of cpus are the almost the same.

anyone knows any kernel paramter to tune for this?

thanks

[Steven Schweda]

> We are tring to uncompress a file [...]

Using what? "uncompress"? Some PA-RISC
program in an emulator?

> [...] it is quite slow.

Define "quite slow".

> [...] it is much faster.

Define "much".

How busy are these systems?

> the number of cpus are the almost the same.

Does your "uncompress a file" program use
more than one CPU?

> [...] any kernel paramter to tune for this?

I doubt it, but with almost no information on
which to make a judgment, who could know?

[kenken_3]

just uncompress filename.tar.Z (same file)

1) Itanium server: it is about 3G for 2 mins
pa-risc server: it is about 4G for 2 mins

2)Itanium: 4 cpu, 16G memory
pa-risc: 1cpu, 2G memory

3)disk io are almost the same 90%

[Steven Schweda]

> 1) Itanium server: it is about 3G for 2 mins
> pa-risc server: it is about 4G for 2 mins

So, "quite slow" means 25% slower? I don't
know how these CPUs compare in rated speed.
Should I assume that this IA64 CPU should be
faster than this PA-RISC CPU?

> How busy are these systems?

Still wondering...


> the number of cpus are the almost the same.

> 2)Itanium: 4 cpu, 16G memory
> pa-risc: 1cpu, 2G memory

So, 75% fewer is "almost the same", but 25%
slower is "quite slow"?

[kenken_3]

the filename.tar.Z is about 70G. So when time goes on, the difference becomes more obvious.

It is my first time to notice such issue. so I don't have any clue on why it behaves like that.

My itanium server should be faster. (I assume)

[Steven Schweda]

> > How busy are these systems?
>
> Still wondering...

Still true.

Perhaps "top" or some other tool could tell
you who's doing what on the two systems.

I can imagine all kinds of differences, busy
CPUs, slow disk, busy disk, fragmented disk,
process priority ("nice"), "uncompress"
program itself (Doesn't gzip do ".Z", too?),
...

> [...] (I assume)

Not the most reliable benchmark test.

[Bob E Campbell]

Steven is right of course. Try using dd to eliminate the CPU from the comparison:

# time dd if=yourFile of=/dev/null bs=1024k

[Steven Schweda]

> # time dd if=yourFile of=/dev/null bs=1024k

Or turn it around (and change "null" to
"zero") to check the write speed instead of
the read speed.

Or redirect the expanded output to the null
device.

Or ...

[Dennis Handly]

You should try glance to see where the bottlenecks are. It is most likely I/O, not CPU.

[Steven Schweda]

> [...] It is most likely I/O, not CPU.

I'm glad that _someone_ knows how busy his
CPUs are. I still don't.

[Hein van den Heuvel]

kenken,

Steven is of course correct, but cranky as ever. He's trying to provoke you to THINK about the data you are providing, what is happening or not happening on the systems and what might explain a difference.

Think about it... (ooops, now I did it :-)... you mentioned "3)disk io are almost the same 90%". So even is the CPU was inifinitely fast, it would seem the at best the speedup could be 10% more.... so it is the disk that defines the performance. 36MB/sec on the PA versus 27 MB/sec on the Itanium would explain it (assuming a hefty compression rate where the input IO throughput can be ignored).

Now I'll be the first to admit that there is a lot of handwaving in the above. 'disk busy' is precise, yet vague. It means there was something happening 90% of the time, but it does not mean that you might have been able to push the IO trough harder/smarter. And the actual (usermode) uncompress CPU usage is largely decoupled, hidden behind, the IO busyness.

That's why we all request more, and more precise data. How much CPU is being used ? (usermode, system). How fast is the IO subsystem... reading .. versus writing.

The 'writes' are more or less free, as long as they eventually find some time. The read speed defines whether the program has to wait for data to work on, or can keep on uncompressing, but the reads might be slowed down by the ongoing write work.

The most likely suspect (imho) is the characteristics of the IO systems provided (simple disk each?). But it could indeed still prove to be an CPU speed or porting issue. Only you can help us determine the more like cause / solution.

hope this helps some,
Hein van den Heuvel
Hvdh Performance Consulting.