RE: 10G and UFS - long write times
- From: "Nilesh Shah" <nshah@xxxxxxxxxxx>
- To: <John.Hallas@xxxxxxxxxxxxxxxxx>, <rshamsud@xxxxxxxxxxxx>, <ganstadba@xxxxxxxxxxx>
- Date: Thu, 8 Jun 2006 10:27:31 -0700
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@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Hallas, John, Tech
Dev
Sent: Thursday, June 08, 2006 7:45 AM
To: rshamsud@xxxxxxxxxxxx; ganstadba@xxxxxxxxxxx
Cc: oracle-l@xxxxxxxxxxxxx
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@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Riyaj Shamsudeen
Sent: 08 June 2006 14:41
To: ganstadba@xxxxxxxxxxx
Cc: oracle-l@xxxxxxxxxxxxx
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?
--
//www.freelists.org/webpage/oracle-l
Other related posts:
