| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> c.d.o.server -> Re: What is better asychronous IO or multiple db_writers?
Hi Neil,
I don't want to turn this into a religious war about raw, but I will venture another response.
When choosing a DBWR setup on HP the choice is between
1) async on raw 2) multiple dbwrs on filesystems 3) mulitple dbwrs on raw
None of us would recommend (3), so it is really a choice between (1) and (2). Because we have to choose between raw and filesystem at the same time that we choose between async and multiple dbwrs, we are at risk of confusing the two issues. I will try to keep them distinct.
Async is better than multiple dbwrs because:
1) it avoids the interprocess communication overheads for
communication between the master and slave DBWRs
2) it avoids the bandwidth limitation of only being able to have 50
slave DBWRs, and only being able to do 50 concurrent I/Os
3) it queues the writes to hp-ux as a batch, which allows the device
driver strategy layer to order them optimally and merge them into
larger I/O requests where possible
4) DBWR clears all of its batch in one large operation, rather than a
series of smaller ones, which reduces the possibility and duration of
write complete wait events.
In summary async has some slight performance advantages under all circumstances, but has very significant bandwidth and thus scalability and thus performance advantages in write intensive instances.
The main argument for raw on HP is that it is needed for async, and you may need the scalability that async allows. However, there are other implications in choosing raw that need to be considered -- namely performance and manageability.
The performance issue is mainly related to the benefits of buffering in the hp-ux buffer cache, versus the cost of maintaining that cache, rather than the length of the code path (which is slightly in favour of raw). Firstly, note that there is no buffering advantage on writes, because dbwr opens the datafiles o_dsync. There can be buffering advantages on reads, particularly due to read-ahead. However, this is only significant if you do sequential access with a multiblock read size of less than 64K or have too few db_block_buffers. Both these factors are readily tunable, and so the buffering argument holds little weight. On the other hand, the management overheads of the buffer cache are significant. Mostly importantly, all readers take a shared lock on the datafile inode which delays dbwr from taking its exclusive lock on the inode to write. This can significantly impact dbwr performance. There is also a slight impact from dbwr on readers. Another aspect of filesystem buffer cache management is that the syncer will flush all filesystem metadata to disk every 30 seconds. Any attempts to modify that metadata (any buffered I/O requests) will block until the physical I/Os have finished. In cases where there are a lot of outstanding I/O requests on some disks (for example, if there were a lot of delayed write blocks in the cache that have just been flushed by syncer) the metadata flush can take in the order of seconds. On a busy system, these filesystem buffer cache management overheads are a significant factor in the outperformance of raw over filesystems.
The management issue is uninteresting to me, but I will say that if you are serious about performance, you should have planned your I/O distribution and capacity growth with such care that the concept of being able to extend or add datafiles on the fly would fill you with horror. I am however sympathetic to those poor souls who are not given time for such planning, or the money for the database monitoring and backup management software that they need.
In summary, given careful tuning raw will perform better than filesystem on a busy system, but there will be no significant difference on a lightly loaded system. Filesystems are more flexible than raw, but flexibility should not be used as a subtitute for proper planning and automation.
I hope that makes my position a bit clearer. Fire awy! :-)
Regards,
Steve Adans
steveadams_at_acslink.net.au
>In article <34c3d97c.74764416_at_newsserver.trl.oz.au>, Steve Adams wrote:
>
>Whilst I appreciate that RAW devices do provide a higher bandwidth, it does
>not necessarily follow that they actually improve performance and scalability.
>
>Filesystems provide buffering which can negate the need to perform actual IO.
>I seem to recall performing some benchmarks on AIX 3.2.5 many moons ago with
>a DB of 5Gb and finding little to choose between RAW and AIX filesystems.
>I am sure that this is not the case for every UNIX flavour,
>HP-UX being a prime candidate for as (certainly prior to HPUX 11) their
>filesystems are not as well implemented as some other O/S's.
>
>Personally I do not use RAW filesystems (except for REDO) if I can help it.
>You lose Oracle functionality (AUTOEXTEND) and RAW filesystems are generally
>more messy to manage.
>
>regs
>
>Neil Chandler
>
>
>p.s. I hope you are right about Filesystem A/IO in HP-UX 11.
>
>>Hello Neil, Peter, Matt and others,
>>
>>Here are some quotes from the "Oracle8 Server Installation Guide for
>>HP 9000" under the heading "Using Asynchronous I/O":
>>"The asynchronous I/O pseudo-driver on HP-UX allows the Oracle Server
>>to perform I/O to raw disk partitions using an asynchronous method,
>>resulting in less I/O overhead and higher throughput."
>>"Oracle Corporation recommends asynchronous I/O on Series 800 systems
>>if the database files are created with raw disk partitions."
>>This is followed by a detailed explanation of how to set it up.
>>
>>There is an alternate asynchronous I/O mechanism in HP-UX (fs_async)
>>which applies to filesystems and does not affect raw I/O. As you have
>>stated, Neil, this is NOT a good idea. It can corrupt your database
>>and your filesystems as well. However, your conculsion does not
>>follow. Using async I/O on raw datafiles provides much higher write
>>bandwidth and scalability than multiple DB writers on either
>>filesystem based or raw datafiles.
>>
>>In HP-UX 11, I believe that there will be a new asynchronous I/O
>>mechanism for filesystem based datafiles, which uses the same
>>technology as Solaris do presently -- namely, simulating multiple
>>DBWR's in the single process using threads. Nevertheless, true
>>asynchronous I/O on raw devices should still outperform this
>>significantly.
>>
>>Regards,
>>Steve Adams
>>steveadams_at_acslink.net.au
>>
>>----------
>>On 19 Jan 1998 15:54:41 GMT, oracle_at_tchp2.tcamuk.stratus.com (Neil
>>Chandler) wrote:
>>
>>>As far a I remember, if you switch on Async-IO on HP-UX (Kernel Parameter)
>>>and have you datafiles in filesystems (ADFS or BSD 4.2),
>>>you can corrupt your database.
>>>
>>>Use multiple DB Writers - (about 2 x No-of-disks works well for me)
>>>
>
Received on Thu Jan 22 1998 - 00:00:00 CST
 |
 |