Re: DBWR, Direct I/O and the Devil

  • From: "Finn Jorgensen" <finn.oracledba@xxxxxxxxx>
  • To: Chris.Taylor@xxxxxxxxxxxxxxx
  • Date: Wed, 28 Nov 2007 16:00:01 -0500

Don,

In regards to your second item, there is no need to set both
filesystemio_options=directio and convosync=direct. They basically do the
samething. I would get rid of the convosync mount option since it may have a
negative impact on other tools as well (any tool opening files with O_SYNC
or D_SYNC flag will use direct IO which may not be optimal).
I would think disk_asynch_io  becomes moot at this point since you're no
longer using asynch IO.

I haven't tested direct IO with multiple db writers, but I haven't read
anything that says direct IO is handed off the same way asynch IO is, so I
suppose there COULD be a benfit to it, but as Chris says below, I haven't
personally been able to squeeze much performance out of that particular
parameter.

Back in 2000 I was managing a database on Solaris 2.6 which experienced a
lot of Spin Mutex'es, which is basically a process spinning on the CPU
waiting for a resource to become available. This was caused by Oracle IO,
and first setting convosync/mincache and later implementing Quick IO fixed
the issue, as well as improved database performance tremendously. That was a
long time ago though, so it may not apply directly today.
In recent testing with writing BLOB's I have seen a slight performance
improvement while using Direct IO over async IO, but slightly worse
performance when doing certain other operations.

HTH
Finn



On 11/28/07, Taylor, Chris David <Chris.Taylor@xxxxxxxxxxxxxxx> wrote:
>
> Don,
>
> Do you believe you have an I/O issue or are you just trying to "squeeze"
> more out of your I/O subsystem?
>
> Having played with db_writer_processes, I haven't really seen much
> improvement or negative impact from increasing/decreasing them.  But
> that is probably more due to the load (or lack thereof to notice any
> difference).
>
>
>
>
>
> Chris Taylor
> Sr. Oracle DBA
> Ingram Barge Company
> Nashville, TN 37205
> Office: 615-517-3355
> Cell: 615-354-4799
> Email: chris.taylor@xxxxxxxxxxxxxxx
>
> -----Original Message-----
> From: oracle-l-bounce@xxxxxxxxxxxxx
> [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Don Seiler
> Sent: Wednesday, November 28, 2007 12:59 PM
> To: Oracle-L Freelists
> Subject: DBWR, Direct I/O and the Devil
>
> I'd like to lay bare some aspects of my instance and see what everyone
> thinks.  I've recently been re-reading Kevin Closson's series on
> over-configuring DBWRs [0], and had some questions.
>
> First of all, this is on Oracle RDBMS 10.2.0.2 Enterprise Edition on
> RHEL4.  Both DB and OS are 64-bit.  Processing is 4 dual-core 64-bit
> CPUs.  Filesystem for all database files is Veritas (vxfs).
>
> Second, based on a suggestion from a colleague, I set
> filesystemio_options=directio.  We also mounted the vxfs drives with
> the convosync=direct option.  However, disk_asynch_io is still true.
> Is there a conflict here?
>
> Third, we have db_writer_processes=4.  This was done a long time ago
> and hasn't been looked at since.  I imagine it was done based on the
> "1 DBWR for every CPU" line of thinking that Kevin spotlights in his
> series.  Our database is a hybrid of OLTP data and bulk-loaded data
> that is either direct-path sqlldr or INSERT/APPEND from external
> tables.  Kevin mentioned that direct-path writes don't use the DBWR,
> so that this instance *might* do perfectly well with just 1 DBWR.  I'm
> wondering if using directio is also a factor in determining the proper
> value of db_writer_processes.
>
> Fourth, should I have even gone to directio in the first place?  I'd
> like to know what people use to benchmark I/O throughput, similar to
> what Kevin does in his tests.
>
> [0]
> http://kevinclosson.wordpress.com/2007/08/10/learn-how-to-obliterate-pro
> cessor-caches-configure-lots-and-lots-of-dbwr-processes/
> --
> Don Seiler
> http://seilerwerks.wordpress.com
> ultimate: http://www.mufc.us
> --
> //www.freelists.org/webpage/oracle-l
>
>
>
>
> --
> //www.freelists.org/webpage/oracle-l
>
>
>

Other related posts:

  1. Home
  2. oracle-l
  3. Archive
  4. 11-2007