HP-UX VxFS tuning and performance - filibeto.org

More documents

Recommendations

Info

22 cio The cio option enables the file system for concurrent I/O. Prior to VxFS 5.0.1, a separate license was needed to use the concurrent I/O feature. Beginning with VxFS 5.0.1, concurrent I/O is available with the OnlineJFS license. Concurrent I/O is recommended with applications which support its use. remount The remount option allows for a file system to be remounted online with different mount options. The mount -o remount can be done online without taking down the application accessing the file system. During the remount, all file I/O is flushed to disk and subsequent I/O operations are frozen until the remount is complete. The remount option can result in a stall for some operations. Applications that are sensitive to timeouts, such as Oracle Clusterware, should avoid having the file systems remounted online. Intent log options There are 3 levels of transaction logging: tmplog – Most transaction flushes to the Intent Log are delayed, so some recent changes to the file system will be lost in the event of a system crash. delaylog – Some transaction flushes are delayed. log – Most all structural changes are logged before the system call returns to the application. Tmplog, delaylog, log options all guarantee the structural integrity of the file system in the event of a system crash by replaying the Intent Log during fsck. However, depending on the level of logging, some recent file system changes may be lost in the event of a system crash. There are some common misunderstandings regarding the log levels. For read() and write() system calls, the log levels have no effect. For asynchronous write() system calls, the log flush is always delayed until after the system call is complete. The log flush will be performed when the actual user data is written to disk. For synchronous write() systems calls, the log flush is always performed prior to the completion of the write() system call. Outside of changing the file‟s access timestamp in the inode, a read() system call makes no structural changes, thus does not log any information. The following table identifies which operations cause the Intent Log to be written to disk synchronously (flushed), or if the flushing of the Intent Log is delayed until sometime after the system call is complete (delayed).
Table 4. Intent log flush behavior with VxFS 3.5 or above Operation log delaylog tmplog Async Write Delayed Delayed Delayed Sync Write Flushed Flushed Flushed Read n/a n/a n/a Sync (fsync()) Flushed Flushed Flushed File Creation Flushed Delayed Delayed File Removal Flushed Delayed Delayed File Timestamp changes Flushed Delayed Delayed Directory Creation Flushed Delayed Delayed Directory Removal Flushed Delayed Delayed Symbolic/Hard Link Creation Flushed Delayed Delayed File/Directory Renaming Flushed Flushed Delayed Most transactions that are delayed with the delaylog or tmplog options include file and directory creation, creation of hard links or symbolic links, and inode time changes (for example, using touch(1M) or utime() system call). The major difference between delaylog and tmplog is how file renaming is performed. With the log option, most transactions are flushed to the Intent Log prior to performing the operation. Note that using the log mount option has little to no impact on file system performance unless there are large amounts of file create/delete/rename operations. For example, if you are removing a directory with thousands of files in it, the removal will likely run faster using the delaylog mount option than the log mount option, since the flushing of the intent log is delayed after each file removal. Also, using the delaylog mount option has little or no impact on data integrity, since the log level does not affect the read() or write() system calls. If data integrity is desired, synchronous writes should be performed as they are guaranteed to survive a system crash regardless of the log level. The logiosize can be used to increase throughput of the transaction log flush by flushing up to 4 KB at a time. The tranflush option causes all metadata updates (such as inodes, bitmaps, etc) to be flushed before returning from a system call. Using this option will negatively affect performance as all metadata updates will be done synchronously. noatime Each time a file is accessed, the access time (atime) is updated. This timestamp is only modified in memory, and periodically flushed to disk by vxfsd. Using noatime has virtually no impact on performance. nomtime The nomtime option is only used in cluster file systems to delay updating the Inode modification time. This option should only be used in a cluster environment when the inode modification timestamp does not have to be up-to-date. 23
Page 1 and 2: HP-UX VxFS tuning and performance T
Page 3 and 4: Understanding VxFS In order to full
Page 5 and 6: File system reorganization attempts
Page 7 and 8: Read ahead with VxVM stripes The de
Page 9 and 10: Figure 4. Flush behind As data is w
Page 11 and 12: The read flush behind feature has t
Page 13 and 14: Note The OnlineJFS license is requi
Page 15 and 16: Concurrent I/O The main problem add
Page 17 and 18: Zero Filled On Demand (ZFOD) extent
Page 19 and 20: Table 3. Default intent log size FS
Page 21: Using datainlog has no affect on no
Page 25 and 26: ead_ahead The default read_ahead va
Page 27 and 28: Unified File Cache on HP-UX 11i v3
Page 29 and 30: Note When setting vx_ninode to redu
Page 31 and 32: Patches Performance problems are of

HP-UX VxFS tuning and performance - filibeto.org

Create successful ePaper yourself

Delete template?

Save as template?