Re: How much RAM is to much
- From: kyle Hailey <kylelf@xxxxxxxxx>
- To: "D'Hooge Freek" <Freek.DHooge@xxxxxxxxx>
- Date: Mon, 18 Apr 2011 17:58:04 -0700
Testing on Solaris, I got direct I/O if either NFS mount was set
forcedirectio or Oracle had the parameter filesystemio_options=directio
The only case I got unix files system caching was when the mount was done
without forcedirectio and filesystemio_options were either none or asynch.
- Kyle
http://dboptimizer.com
PS used dtrace on solaris to watch the file system access to see whether the
query was going to disk or not and watching the number of physical reads
with autotrace in sqlplus. The query was definitely doing the same physical
reads in all cases and in all cases the disks were accessed except when the
NFS mount was done without forcedirectio and filesystemio_options were
either none or asynch. Query was doing
87129 consistent reads
77951 physical reads
Of course the response time of the query was a good indicator. The second
execution of the query with Unix caching was about 5 seconds, with direct
I/O and 32K resize/wsize on the NFS mount it was 60 seconds and with 1M
rsize/wsize on the NFS mounts it was 30 seconds. (Looks like the rsize/wsize
can have a big impact )
For this table, when cached in the buffer cache, it too 2 seconds, ie no
physical reads.
On Fri, Feb 11, 2011 at 3:11 PM, D'Hooge Freek <Freek.DHooge@xxxxxxxxx>wrote:
> Gaja,
> X-archive-position: 34399
> X-ecartis-version: Ecartis v1.0.0
> Sender: oracle-l-bounce@xxxxxxxxxxxxx
> Errors-to: oracle-l-bounce@xxxxxxxxxxxxx
> X-original-sender: Freek.DHooge@xxxxxxxxx
> Precedence: normal
> Reply-To: Freek.DHooge@xxxxxxxxx
> List-help: <mailto:ecartis@xxxxxxxxxxxxx?Subject=help>
> List-unsubscribe: <oracle-l-request@xxxxxxxxxxxxx?Subject=unsubscribe>
> List-software: Ecartis version 1.0.0
> List-Id: oracle-l <oracle-l.freelists.org>
> X-List-ID: oracle-l <oracle-l.freelists.org>
> List-subscribe: <oracle-l-request@xxxxxxxxxxxxx?Subject=subscribe>
> List-owner: <mailto:steve.adams@xxxxxxxxxxxx>
> List-post: <mailto:oracle-l@xxxxxxxxxxxxx>
> List-archive: <//www.freelists.org/archives/oracle-l>
> X-list: oracle-l
>
> This explains why the forcedirectio mount option is required with NFS on
> solaris.
> But I always thought that setting the filesystemio_options parameter to
> directIO or setall caused the processes to open the files with the O_DIRECT
> flag. If so, would this then not cause the file to be accessed with directio
> despite any setting on the filesystem?
>
> I'm working mainly on linux these days (either with nfs or asm), so not
> much chance in testing this.
>
>
> Regards,
>
>
> Freek D'Hooge
> Uptime
> Oracle Database Administrator
> email: freek.dhooge@xxxxxxxxx
> tel +32(0)3 451 23 82
> http://www.uptime.be
> disclaimer: www.uptime.be/disclaimer
> ---
> From: Gaja Krishna Vaidyanatha [mailto:gajav@xxxxxxxxx]
> Sent: vrijdag 11 februari 2011 22:47
> To: D'Hooge Freek
> Cc: Oracle-L List
> Subject: Re: How much RAM is to much
>
> Hi Freek,
>
> What you said is true for filesystems that do NOT allow "direct I/O" mount
> options in their respective mount commands. But for those filesystems that
> do (i.e. vxfs, jfs etc) support the relevant direct I/O mount options, the
> direct I/O mount option has always (in my experience) been required in
> addition to setting filesystemio_options to SETALL. Setting just the
> filesystemio_options in the init.ora (in those cases) did not create the
> desired result.
>
> If you have observed the "lack of the mount option" in recent times on
> those filesystems where direct I/O mount options ARE supported (i.e. vxfs,
> jfs etc), please advise. There is always something to learn new each day :)
>
> Cheers,
>
> Gaja
>
> Gaja Krishna Vaidyanatha,
> Founder/Principal, DBPerfMan LLC
> http://www.dbperfman.com
> Phone - 001-(650)-743-6060
> Co-author:Oracle Insights:Tales of the Oak Table -
> http://www.apress.com/book/bookDisplay.html?bID=314
> Co-author:Oracle Performance Tuning 101 -
> http://www.amazon.com/gp/reader/0072131454/ref=sib_dp_pt/102-6130796-4625766
> --
> //www.freelists.org/webpage/oracle-l
>
>
>
Other related posts:
