Re: DBWR, Direct I/O and the Devil

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_at_ingrambarge.com> 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_at_ingrambarge.com
>
> -----Original Message-----
> From: oracle-l-bounce_at_freelists.org
> [mailto:oracle-l-bounce_at_freelists.org] 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
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>

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