7 Tuning the WebLogic Persistent Store

The following sections explain how to tune the persistent store, which provides a built-in, high-performance storage solution for WebLogic Server subsystems and services that require persistence.

Overview of Persistent Stores

The following sections provide information on using persistent stores.

Using the Default Persistent Store

Each server instance, including the administration server, has a default persistent store that requires no configuration. The default store is a file-based store that maintains its data in a group of files in a server instance's data\store\default directory. A directory for the default store is automatically created if one does not already exist. This default store is available to subsystems that do not require explicit selection of a particular store and function best by using the system's default storage mechanism. For example, a JMS Server with no persistent store configured will use the default store for its Managed Server and will support persistent messaging. See:

Using Custom File Stores and JDBC Stores

In addition to using the default file store, you can also configure a file store or JDBC store to suit your specific needs. A custom file store, like the default file store, maintains its data in a group of files in a directory. However, you may want to create a custom file store so that the file store's data is persisted to a particular storage device. When configuring a file store directory, the directory must be accessible to the server instance on which the file store is located.

A JDBC store can be configured when a relational database is used for storage. A JDBC store enables you to store persistent messages in a standard JDBC-capable database, which is accessed through a designated JDBC data source. The data is stored in the JDBC store's database table, which has a logical name of WLStore. It is up to the database administrator to configure the database for high availability and performance. See:

Using JMS Paging Stores

Each JMS server implicitly creates a file based paging store. When the WebLogic Server JVM runs low on memory, this store is used to page non-persistent messages as well as JDBC store persistent messages. Depending on the application, paging stores may generate heavy disk activity.

Note:

File store persistent messages do not page using a paging store, such messages page directly into and out of their respective file stores.

JMS paging stores usually require no tuning. You can optionally change the directory location and the thresholds setting at which paging begins. See Tuning Applications Using Unit-of-Order.

Best Practices When Using Persistent Stores

  • For subsystems that share the same server instance, share one store between multiple subsystems rather than using a store per subsystem. Sharing a store is more efficient for the following reasons:

    • A single store batches concurrent requests into single I/Os which reduces overall disk usage.

    • Transactions in which only one resource participates are lightweight one-phase transactions. Conversely, transactions in which multiple stores participate become heavier weight two-phase transactions.

    For example, configure all SAF agents and JMS servers that run on the same server instance so that they share the same store.

  • Add a new store only when the old store(s) no longer scale.

Tuning JDBC Stores

The location of the JDBC store DDL that is used to initialize empty stores is now configurable. This simplifies the use of custom DDL for database table creation, which is sometimes used for database specific performance tuning. For information, see "Create JDBC stores" in Oracle Fusion Middleware Oracle WebLogic Server Administration Console Help and "Using the WebLogic Persistent Store" in Oracle Fusion Middleware Configuring Server Environments for Oracle WebLogic Server.

Tuning File Stores

The following section provides information on tuning File Stores:

Basic Tuning Information

The following section provides general information on tuning File Stores:

  • For basic (non-RAID) disk hardware, consider dedicating one disk per file store. A store can operate up to four to five times faster if it does not have to compete with any other store on the disk. Remember to consider the existence of the default file store in addition to each configured store and a JMS paging store for each JMS server.

  • Use Direct-Write synchronous write policy.

    • For releases of WebLogic Server 9.0 and higher, Direct-Write is the default write policy. In most applications Direct-Write provides better performance than the Cache-Flush write policy.

      Note:

      The Direct-Write write-policy (default) can be unsafe on Microsoft Windows. As with other vendors that use a direct write policy, MS-Windows system administrators must ensure that the Windows disk configuration doesn't cache direct-writes in memory instead of flushing them to disk. See "getSynchronousWritePolicy" in Oracle Fusion Middleware Oracle WebLogic Server Administration Console Help.

    • File stores in releases prior to WebLogic Server 9.0 default to the Cache-Flush write policy.

  • The Disabled write-policy option can dramatically improve performance, especially at low client loads. However, it is unsafe because writes become asynchronous and data can be lost in the event of Operating System or power failure.

  • When performing head-to-head vendor comparisons, make sure all the write policies for the persistent store are equivalent. Some non-WebLogic vendors default to the equivalent of Disabled.

  • If disk performance continues to be a bottleneck, consider purchasing disk or RAID controller hardware that has a built-in write-back cache. These caches significantly improve performance by temporarily storing persistent data in volatile memory. To ensure transactionally safe write-back caches, they must be protected against power outages, host machine failure, and operating system failure. Typically, such protection is provided by a battery-backed write-back cache.

Tuning the File Store Direct-Write Policy

For file stores with the synchronous write policy of Direct-Write, you may be directed by Oracle Support or a release note to set weblogic.Server options on the command line or start script of the JVM that runs the store:

  • Globally changes all stores running in the JVM:

    -Dweblogic.store.AvoidDirectIO=true

  • For a single store, where store-name is the name of the store:

    -Dweblogic.store.store-name.AvoidDirectIO=true

  • For the default store, where server-name is the name of the server hosting the store:

    -Dweblogic.store._WLS_server-name.AvoidDirectIO=true

Setting AvoidDirectIO on an individual store overrides the setting of the global -Dweblogic.store.AvoidDirectIO option. For example: If you have two stores, A and B, and set the following options:

-Dweblogic.store.AvoidDirectIO=true
-Dweblogic.store.A.AvoidDirectIO=false

then only store B has the setting AvoidDirectIO=true.

Note:

Setting the AvoidDirectIO option may have performance implications which often can be mitigated using the block size setting described in Tuning the File Store Block Size.

Tuning the File Store Block Size

You may want to tune the file store block size for file stores that are configured with a synchronous write policy of Direct-Write (default) or Cache-Flush, especially when using AvoidDirectIO=true as described in Tuning the File Store Direct-Write Policy or for systems with a hard-drive-based write-back cache where you see that performance is limited by physical storage latency.

Consider the following example:

  • A single WebLogic JMS producer sends persistent messages one by one.

  • The network overhead is known to be negligible.

  • The file store's disk drive has a 10,000 RPM rotational rate.

  • The disk drive has a battery-backed write-back cache.

and the messaging rate is measured at 166 messages per second.

In this example, the low messaging rate matches the disk drive's 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 store's 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 I/O 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.

Setting the Block Size for a File Store

To set the block size of a store, use one of the following properties on the command line or start script of the JVM that runs the store:

  • Globally sets the block size of all file stores that don't have pre-existing files.

    -Dweblogic.store.BlockSize=block-size

  • Sets the block size for a specific file store that doesn't have pre-existing files.

    -Dweblogic.store.store-name.BlockSize=block-size

  • Sets the block size for the default file store, if the store doesn't have pre-existing files:

    -Dweblogic.store._WLS_server-name. BlockSize=block-size

The value used to set the block size is an integer between 512 and 8192 which is automatically rounded up to the nearest multiple of 512.

Setting BlockSize on an individual store overrides the setting of the global -Dweblogic.store.BlockSize option. For example: If you have two stores, A and B, and set the following options:

-Dweblogic.store.BlockSize=8192
-Dweblogic.store.A.BlockSize=512

then store B has a block size of 8192 and store A has a block size of 512.

Note:

Setting the block size using command line properties only takes effect for file stores that have no pre-existing files. If a store has pre-existing files, the store continues to use the block size that was set when the store was first created.

Determining the File Store Block Size

You can verify a file store's current block size and synchronous write policy by viewing the server log of the server that hosts the store. Search for a "280050" store opened message.

Determining the File System Block Size

To determine your file system's actual block size, consult your operating system documentation. For example:

  • Linux ext2 and ext3 file systems: run /sbin/dumpe2fs /dev/device-name and look for "Block size"

  • Windows NTFS: run fsutil fsinfo ntfsinfo device letter: and look for "Bytes Per Cluster"

Converting a Store with Pre-existing Files

If the data in a store's pre-existing files do not need to be preserved, then simply shutdown the host WebLogic Server instance and delete the files to allow the block size to change when the store is restarted. If you need to preserve the data, convert a store with pre-existing files to a different block size by creating a version of the file store with the new block size using the compact command of the command line store administration utility:

  1. java -Dweblogic.store.BlockSize=block-size weblogic.store.Admin

  2. Type help for available commands.

  3. Storeadmin->compact -dir file-store-directory

See "Store Administration Using a Java Command-line" in Oracle Fusion Middleware Configuring Server Environments for Oracle WebLogic Server.