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.