RE: 10G and UFS - long write times

One more option worth trying with ufs is using -r option (setting the rpm speed of the disk). By default solaris sets the disk rpm speed to 3200, so if you have a 10000 rpm drive it will still rotate at 3600 rpm. On the downside you need to recreate the filesystem to add this option      

Nilesh  

From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Hallas, John, Tech Dev
Sent: Thursday, June 08, 2006 7:45 AM
To: rshamsud_at_jcpenney.com; ganstadba_at_hotmail.com Cc: oracle-l_at_freelists.org
Subject: RE: 10G and UFS - long write times  

All valid points, however in what is a complicated scenario for us I am trying to keep it as simple as possible

The test scenario I used was developed as a direct response to the realisation that we were having problems wit transaction with many writes.

This was borne out when a Windows PC was 20 times faster than a Sun V440 server.  

I will take the comments on board.  

The latest information we can see is that mounting a UFS disk with the directio and logging option seems to resolve the problem and improve performance OF THAT TEST by a very considerable factor. Previously, logging was the only mount option used (other than defaults), however I am not an Unix SA so I do stand to be corrected on that point.

It does appear that 10G , for whatever reason, seems to be affected much more FOR THIS TEST AND OTHER WRITES than 9i was.  

John  

From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Riyaj Shamsudeen Sent: 08 June 2006 14:41
To: ganstadba_at_hotmail.com
Cc: oracle-l_at_freelists.org
Subject: Re: 10G and UFS - long write times  

John

    Michael McMullen hit the point here, precisely.

>>We are seeing big problems when issuing disk writes using 10G
(both 10.1 and 10.2).

    What tool did you use to see the write response time ? Did you trace DBWR or LGWR to see the write response time and IO related waits ? Assuming unix, does iostat indicates worse average response time for those devices ?

>>The test is very simple and quick to do
    And potentially misleading too. This test case is proving that having very high commit frequency will introduce additional performance issues.

  >> On 10G using local UFS disk the time various from 7:00 to 9:00 minutes and is very repeatable.

    Is this code that you posted here takes this long ? What files are in the UFS disk? Whole database or just log files?

    If you want to understand why why your code is slower, turn on SQLtrace in 9i and in 10g for your test case. Then find where that extra time is spent. Also, compare session statistics between 9i and 10g. That will tell you where to concentrate. Further, log file sync and log buffer waits are not just IO related. You might want to decrease your commit frequency to eliminate these events from the equation too.

    There are so many different optimization techniques introduced in 10g, your test case might be probing the vulnerability of a feature.

Thanks
Riyaj Shamsudeen

Michael McMullen wrote:

I understand that there is a severe difference in timings. But is it right
to test fundamentally bad code? I've been testing 10g on a Sun T2000, both
on the san and local disks. I never could get it as fast as my 8i/9i installations on other servers. Granted, I was not comparing apples and oranges. I had to give it back before I could bring 9i on the T2000 to test.
But my initial reaction with 10g is it just didn't seem as forgiving as other versions of oracle.
How about testing a big import with lots of parallel index creation?

--
http://www.freelists.org/webpage/oracle-l
 
 
 
  

 


--
http://www.freelists.org/webpage/oracle-l