Re: Performance difference between 2 machines

From: Etunimi Sukunimi <etunimi.sukunimi_at_sonera.com>
Date: Wed, 22 Jun 2005 10:26:29 GMT
Message-ID: <p1bue.106$K76.47@read3.inet.fi>

Noons wrote:
> Etunimi Sukunimi apparently said,on my timestamp of 21/06/2005 7:20 PM:
>

>>But wouldn't the trace file output suggest that the processors are
>>waiting for something?

>
>
> Yes, absolutely. Something.
>
>

>>Remember that the sql-command given was "select count(1) from TABLE_A",
>>that doesn't really need that much of processing power.

>
>
> Well yes, but what is the NATURE of that wait? What you have from
> the Oracle trace is approx 200 secs of *Oracle* waiting for
> scattered read, but that is no confirmation whatsoever that
> there are no waits outside of Oracle or CPU is free.
>
> Remember: the Oracle trace measures overall time elapsed from
> start of Oracle event to end of Oracle event. If that event does
> IO in the middle, then it is quite possible you may have time
> blow outs that have nothing to do with time waited in Oracle
> itself.
>
> Unless you are using raw datafiles, in HP you will not be using
> aio nor direct io. That means everytime there is an IO request
> from Oracle, HPUX takes over and passes it to the file system
> layer, which then passes it to the device driver and the hardware,
> THEN sits in there twiddling its thumbs on a tight wait loop
> until the disk hardware returns. When that happens, the CPU must
> now go through the return path of the file system, then the OS,
> then back to Oracle. All the while copying 16K of buffered IO
> until it eventually makes its way back into the SGA.
>
> You see this in sar for example as IOwait%, but that doesn't
> mean your CPUs aren't flat out: they are, copying 16k buffers
> and executing all that layer code. It just gets counted as IO
> wait, that is merely a convention of *n*x.
>
> It doesn't come out of thin air, it comes out of processing
> cycles. Which are slower in the 9k/800 than in the P4.
>
> Hence the difference?
>
>
> But I still suspect there is something very wrong with your
> IO hardware. Can you run some tests with dd on both systems
> to gauge the non-db baseline IO speed? There is a very simple
> script I left in www.dizwell.com forum, maybe you could use that?
> It's here:
>
> http://www.phpbbserver.com/phpbb/viewtopic.php?t=120&postdays=0&postorder=asc&start=15&mforum=dizwellforum
>
> and you don't have to sign up to look at it. Just cut and
> paste, run that on both systems in a suitable mount point,
> then compare times. I'll bet you'll get some marked
> differences.
>
>
> --
> Cheers
> Nuno Souto
> in sunny Sydney, Australia
> wizofoz2k_at_yahoo.com.au.nospam
>

Okey, I have attached two text files.

There isn't that much difference in write times, but the read times look quite alarming.

Using 16K block size, customer's machine takes a second to complete, but our machine takes 0.159 seconds. That is over six times slower.

That does look conclusive enough for me, but what would you say?

G: Mikael

1MByte write block size
400+0 records in
400+0 records out

real        5.2
user        0.0
sys         0.7

32KByte write block size
12500+0 records in
12500+0 records out

real        2.3
user        0.0
sys         2.2

16KByte write block size
25000+0 records in
25000+0 records out

real        3.5
user        0.0
sys         3.3

8KByte write block size
50000+0 records in
50000+0 records out

real        3.0
user        0.1
sys         2.8

4KByte write block size
100000+0 records in
100000+0 records out

real        5.0
user        0.2
sys         4.6

2KByte write block size
200000+0 records in
200000+0 records out

real        6.1
user        0.4
sys         5.5

1KByte write block size
400000+0 records in
400000+0 records out

real        8.5
user        0.8
sys         7.4

===========================================================

1MByte input block size
390+1 records in
390+1 records out

real        3.3
user        0.0
sys         0.2

64KByte input block size
6250+0 records in
6250+0 records out

real        0.9
user        0.0
sys         0.9

32KByte input block size
12500+0 records in
12500+0 records out

real        0.9
user        0.0
sys         0.9

16KByte input block size
25000+0 records in
25000+0 records out

real        1.0
user        0.0
sys         0.9

8KByte input block size
50000+0 records in
50000+0 records out

real        1.1
user        0.0
sys         1.0

4KByte input block size
100000+0 records in
100000+0 records out

real        1.5
user        0.1
sys         1.3

2KByte input block size
200000+0 records in
200000+0 records out

real        2.7
user        0.3
sys         2.2

1KByte input block size
400000+0 records in
400000+0 records out

real 4.5 user 0.7 sys 3.5