Setting the Block Size for a File Store Determining the File Store Block Size Determining the File System Block Size
Tuning the WebLogic Persistent Store 8-7
In this example, the low messaging rate matches the disk drives latency 10,000 RPM 60 seconds = 166 RPS even though a much higher rate is expected due to the
battery-backed write-back cache. Tuning the stores block size to match the file systems block size could result in a significant improvement.
In some other cases, tuning the block size may result in marginal or no improvement:
■
The caches are observed to yield low latency so the IO subsystem is not a significant bottleneck.
■
Write-back caching is not used and performance is limited by larger disk drive latencies.
There may be a trade off between performance and file space when using higher block sizes. Multiple application records are packed into a single block only when they are
written concurrently. Consequently, a large block size may cause a significant increase in store file sizes for applications that have little concurrent server activity and
produce small records. In this case, one small record is stored per block and the remaining space in each block is unused. As an example, consider a Web Service
Reliable Messaging WS-RM application with a single producer that sends small 100 byte length messages, where the application is the only active user of the store.
Oracle recommends tuning the store block size to match the block size of the file system that hosts the file store typically 4096 for most file systems when this yields a
performance improvement. Alternately, tuning the block size to other values such as paging and cache units may yield performance gains. If tuning the block size does not
yield a performance improvement, Oracle recommends leaving the block size at the default as this helps to minimize use of file system resources.