General
cancel
Showing results for 
Search instead for 
Did you mean: 

Progress lv and filesystem options for best performance

SOLVED
Go to solution
Darrell Allen
Honored Contributor

Progress lv and filesystem options for best performance

Hi all,

I've inherited an 11.0 N400 running Progress 83d. Our databases are defined as jfs (online JFS 3.1) filesystems on EMC luns (Symmetrix with mirrored disks).

I'd like suggestions for best performance, especially with lvcreate options, mount options, etc.

Some specific questions:

1. Does lvm striping of a logical volume on a mirrored EMC lun help more than spreading out the db extents over multiple filesystems?

2. Should mount -nolog be used?

3. Should mount -o mincache=direct be used?

Any suggestions and explanations are appreciated.

Thanks,
Darrell
"What, Me Worry?" - Alfred E. Neuman (Mad Magazine)
8 REPLIES
Darrell Allen
Honored Contributor

Re: Progress lv and filesystem options for best performance

PS: database startup and creation tips are also appreciated. Also URL's pointing to good doc / support sites for Progress on HPUX.

Thanks again,
Darrell
"What, Me Worry?" - Alfred E. Neuman (Mad Magazine)
James R. Ferguson
Acclaimed Contributor
Solution

Re: Progress lv and filesystem options for best performance

Hi Darrell:

1. I think the choice of LVM striping vs. LVM distributed extents depends on what level of granularity you want, *and* whether or not your environment is OLTP-based or oriented to large, sequential access through large tables.

I'd certainly choice one or the other rather than "isolating" large portions of logical volumes on one physical disk.

2. I would *not* mount with the 'nolog' option. This is intended for memory resident of temporaray filesystems. See the man pages for 'mount_vxfs' for more information.

3. I like the following mount options:

delaylog,nodatainlog,mincache=direc
t,convosync=direct

In this fashion, performance is increased because the file system buffer cache to be bypassed.

Regards!

...JRF...
oiram
Regular Advisor

Re: Progress lv and filesystem options for best performance

Hi,

Some intereste things related with Block size in DB is that you must select a block size for the DB at least equal to the OS block size but the optimal size for it depends on which kind of DB do you want to install. For example in an OLTS you must set the DB block size at the lowest possible value but in a Datawarehouse you would prefer a bigger value for the DB block size.

In www.docs.hp.com you can find information about hpux.

http://www.docs.hp.com/hpux/onlinedocs/B3929-90011/B3929-90011.html

Another good forum is www.tek-tips.com

Best regards
S.K. Chan
Honored Contributor

Re: Progress lv and filesystem options for best performance


http://www.progress.com

If you look at "patches" version 8.3D will retire on Feb 4 2002. Just FYI.
James R. Ferguson
Acclaimed Contributor

Re: Progress lv and filesystem options for best performance

Hi (again) Darrell:

I might add that one of the simplest summaries of Online JFS mount options I've seen is this reproduction from Technicall Knowledge Base document #KBRC00007737:

/begin_quote/

Online JFS 3.1

-o delaylog ??? Intent log writes are asynchronous. ???Double??? write will still occur but the process does not block while the intent log is being written to ?? potential performance increase.

-o tmplog ??? Intent log writes are delayed; recent changed will be lost if the system crashes. This option is recommended for temporary file systems.

-o mincache=direct ??? All reads and non O_SYNC writes are unbuffered. This degrades performance. The trade-off is to reduce the need for pages in buffer cache versus process blocking. Use for large I/O direct from the application.

-o mincache=tmpcache ??? Disable delayed writes and extent clears when file is extended; explicit fsync required to post changes. The trade-off is data integrity versus performance. This option is useful for temporary files.

-o convosync=direct ??? Converts reads and O_SYNC writes to unbuffered. Improve the performance. The trade-off is between increased
performances when source code is not available versus possible loss of data integrity.

-o nodatainlog ??? Posts O_SYNC writes of the data directly to the file. Improve performance. The trade-off is a fewer writes with possibly increased head movement versus double writes with less head moves.

Note: In order to use these options, customer must have the OnlineJFS.

/end_quote/

Regards!

...JRF...
Deshpande Prashant
Honored Contributor

Re: Progress lv and filesystem options for best performance

 
Take it as it comes.
Darrell Allen
Honored Contributor

Re: Progress lv and filesystem options for best performance

Thanks for the replies. If anyone else would care to share your experiences and what works for you (as James has done), I'd like to hear from you.

Thanks,
Darrell
"What, Me Worry?" - Alfred E. Neuman (Mad Magazine)
Parag Chaudhari
Occasional Advisor

Re: Progress lv and filesystem options for best performance

But due to SYmm which does its own data caching, wouldn't all these options be superfluous ??

I think it is better to put full logging, convosync=direct etc. ie the caching should be set to minimal on the OS side.

Also when the system writes to symm, it will be writing to the symm cache and symm will immediately return acks for writing, it is better to use full capabilities of the filesystem rather than worry about the speed.

any comments ????