Re: CPU upgrade caused application slow down

From: zhu chao <chao_ping_at_vip.163.com>
Date: Fri, 30 Apr 2004 18:34:37 +0800
Message-ID: <000f01c42e9e$be8627b0$2552fc0a@corp.ebay.com>

Hi, Tim:

The network traffic of the db server is 15-20Mbit/Second, not MB/Second. Sorry for the confusion. We are running 100Based LAN between application server and database server.

Actully as I said in earlier posts, we upgraded two db servers. The other one which has cpu upgrade from 12*400MHZ to 8*900MHZ does have less application response time after upgrade. Average response time for typical service dropped 30-50 percent.

But applications running on this server does not. The typical application response increased for about 5%. This seems strange. We really cannot explain to boss.

Thanks
Zhu Chao.

Original Message ----- From: "Tim Gorman" <tim_at_sagelogix.com> To: <oracle-l_at_freelists.org> Sent: Friday, April 30, 2004 6:12 PM Subject: Re: CPU upgrade caused application slow down

> Zhu Chao,
>
> Sustained rates of 15-20 Mbytes/sec is absolute network saturation if
you'r=
> e
> running 100BaseT - don=B9t forget that 100 Mbits/sec is 12.5 Mbytes/sec.
Eve=
> n
> if the network segment closest to the server is GigE, you might have a
> network segment somewhere in the mix running at 100BaseT, perhaps?
>
> Cary's remarks aren't theory, of course. Making one component of the
stack
> of technology much faster will almost certainly cause a bottleneck in
> another component. Think of a 10-mile (16 km) roadway where the first 6
> miles (10 km) are expanded to 4 lanes while the remainder is left at 2
> lanes. That was the situation in my hometown (Evergreen, Colorado) some
> years ago -- guess whether the roadway expansion helped improve traffic
flo=
> w
> or caused massive backups where the lanes reduced from 4 to 2...?
>
> Just some thoughts...
>
> -Tim
>
>
> > 1.. According to Cary Millsap=A1=AFs theory, upgrade CPU *CAN* make
performan=
> ce
> > worse. In his case, SQL*Net was the bottleneck. Our server network
traffi=
> c is
> > only at 15-20Mb/Second. This seems not like the bottleneck, Though from
1=
> 0046
> > trace report, sqlnet wait is the NO.1 wait event, but this is normal for
=
> most
> > applications. I also tried to change the tnsnames.ora and listener.ora
w=
> ith
> > larger SDU/TDU of 8KB, restarted tuxedo service and oracle listener. And
> > compare the performance data leter. This does not make much difference
fo=
> r
> > application response time.
> >=20
> > 2.. We did some pure simple SQL test. Result in appendix 1. SAME SQL in
> > 1200MHZ CPU does run faster.
> >=20
> > 2.. We write a simple tuxedo service run the same SQL for 1000 times.
> > Everytime the SQL is transferred through SQL*Net and result is fetched
in=
> to
> > host variable. The result still shows that it runs faster on 1200MHZ
CPU.=
> The
> > average response time in 1200MHZ server is 12.12ms ,and the average
respo=
> nse
> > time in 900mhz server is 14.20ms.
>
> ----------------------------------------------------------------
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> ----------------------------------------------------------------
> To unsubscribe send email to: oracle-l-request_at_freelists.org
> put 'unsubscribe' in the subject line.
> --
> Archives are at http://www.freelists.org/archives/oracle-l/
> FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
> -----------------------------------------------------------------
>
>

Please see the official ORACLE-L FAQ: http://www.orafaq.com

To unsubscribe send email to: oracle-l-request_at_freelists.org put 'unsubscribe' in the subject line.

--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------

Received on Fri Apr 30 2004 - 05:31:47 CDT