topic Re: mincache vs. convosync in Operating System - HP-UX

mincache vs. convosync

Jason Fedynak — Thu, 03 May 2007 17:10:20 GMT

So we started seeing a bunch of buffer cache waits on our oracle DB mount points which are connected to XP frames which has its own buffer cache. We decided to turn on mincache=direct but didn't turn on convosync=direct as the same time. We are now looking into convosync. Trying to read up on the definition of both is a bit confusing. In laymans terms - What is the difference?...

Thanks for any clarification!!

Re: mincache vs. convosync

James R. Ferguson — Thu, 03 May 2007 17:18:58 GMT

Hi Jason:

See:

http://www.docs.hp.com/en/5576/JFS_Tuning.pdf

Regards!

...JRF...

Re: mincache vs. convosync

A. Clay Stephenson — Thu, 03 May 2007 18:23:31 GMT

If you are going to do this then you want to mincache=direct,convosync=direct AND I strongly suggest that you add nodatainlog as well.

On 11.11 and up, I typically see better performance with simply nodatainlog and let the buffer cache do its job, even with large DB SGA's, and large array caches --- assumming your box has plenty of memory and CPU.

Re: mincache vs. convosync

Jason Fedynak — Tue, 08 May 2007 15:31:22 GMT

I just did a search on nodatainlog and found the following, would this not impact performance?:

nodatainlog
The nodatainlog mode should be used on systems with disks that do not
support bad block revectoring. Normally, a VxFS file system uses the
intent log for synchronous writes. The inode update and the data are
both logged in the transaction, so a synchronous write only requires one
disk write instead of two. When the synchronous write returns to the
application, the file system has told the application that the data is
already written. If a disk error causes the data update to fail, then the
file must be marked bad and the entire file is lost.
If a disk supports bad block revectoring, then a failure on the data
update is unlikely, so logging synchronous writes should be allowed. If
the disk does not support bad block revectoring, then a failure is more
likely, so the nodatainlog mode should be used.
A nodatainlog mode file system should be approximately 50 percent
slower than a standard mode VxFS file system for synchronous writes.
Other operations are not affected

Our current mount points on this server are mounted as follows: (we have datainlog)
/dev/vg0x/lvol1 /u0x vxfs rw,suid,largefiles,mincache=direct,delaylog,datainlog 0 2

System has 32GB memory and 16x875 PA-Risc processors.

Re: mincache vs. convosync

Court Campbell — Tue, 08 May 2007 15:38:25 GMT

Is this a trick question?

SEP already answered this:

> On 11.11 and up, I typically see better performance with simply nodatainlog

Re: mincache vs. convosync

A. Clay Stephenson — Tue, 08 May 2007 15:44:26 GMT

Well, we can have dueling experts but I suggest that you read this paper which cites the very same document you do concerning nodatainlog vs datainlog and proceeds to disagree with the datainlog setting just as my experimental results have indicated.

http://h21007.www2.hp.com/dspp/files/unprotected/devresource/Docs/TechPapers/UXPerfCookBook.pdf

In any event, the real way to test this is to vary the mount options and get some metrics because that will tell you what are the optimum settings for your environment.

Re: mincache vs. convosync

Jason Fedynak — Tue, 08 May 2007 15:44:41 GMT

Sorry, I just read the last paragraph..

"A nodatainlog mode file system should be approximately 50 percent slower than a standard mode VxFS file system for synchronous writes. Other operations are not affected"

Re: mincache vs. convosync

Jason Fedynak — Tue, 08 May 2007 15:47:37 GMT

Well thanks for the help. We will take a good look modifying the mount options and monitor our performance.

THanks, again.