Re: How much RAM is to much
- From: kyle Hailey <kylelf@xxxxxxxxx>
- To: Oracle-L List <oracle-l@xxxxxxxxxxxxx>
- Date: Tue, 19 Apr 2011 10:35:41 -0700
I'm wondering why there is the recommendation to use "forcedirectio" on the
,mount options when it seems, at least on solaris, that
filesystemio_options=directio is sufficient for using direct I/O?
- Kyle
http://dboptimizer.com
On Mon, Apr 18, 2011 at 5:58 PM, kyle Hailey <kylelf@xxxxxxxxx> wrote:
>
> 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:
