RE: How much RAM is to much

From: Yong Huang <yong321_at_yahoo.com>
Date: Sun, 13 Feb 2011 10:41:30 -0800 (PST)
Message-ID: <386820.32958.qm_at_web80602.mail.mud.yahoo.com>



> 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.

I can confirm what Freek said, on my Oracle 10.2.0.4, Red Hat 5 kernel 2.6.18-194.17.1.el5 architecture x86_64 if these details matter. The filesystem is ext3, mounted with no option (i.e. everything default). When the process opens a datafile for the first time, I can see the flags passed to open() call in strace are O_RDWR|O_SYNC|O_DIRECT.

By the way, ever since page cache is introduced to the file system, we should make a distinction between buffer cache and page cache. What's interesting here is page cache, because buffer cache caches file system metadata. Well, in Linux, I believe buffer cache is physically inside page cache. So you may call those buffers "buffer pages". Confusing name indeed. But to make it short, as soon as you have the word "buffer" in it, people knowing Linux kernel (not me!) will think you're referring to the cache for metadata, not for file content, which may be what you want to say.

Last point. While Oracle manages data in memory through a better mechanism because it knows the data better, leaving the decision of caching/not caching to the file system is not that dreadful. In some cases, it may even be a big help. So instead of assigning most memory to Oracle buffer cache and using direct I/O, someone can make a comprehensive test to see if locking a large portion of RAM to SGA (through HugePages etc.) and leaving file system to NOT direct I/O will be even better in some cases. If a table slightly bigger than 2% of the buffer cache is frequently full-scanned, and you didn't do anything special about it, I think it's better to let the file system cache its content.

Yong Huang       

--
http://www.freelists.org/webpage/oracle-l
Received on Sun Feb 13 2011 - 12:41:30 CST

Original text of this message