| |
File Store: Configuration
Configuration Options Related Tasks Related Topics
Use this page to configure a disk-based file store for storing subsystem data, such as persistent JMS messages or Store-and-Forward messages.
Configuration Options
Name Description Name The name of this file store. This name must be unique within a WebLogic domain.
MBean Attribute:
WebLogicMBean.NameChanges take effect after you redeploy the module or restart the server.
Synchronous Write Policy The disk write policy that determines how the file store writes data to disk.
This policy also affects the JMS file store's performance, scalability, and reliability. Oracle recommends
Direct-Write-With-Cachewhich tends to have the highest performance. The default value isDirect-Write. The valid policy options are:
Direct-WriteDirect I/O is supported on all platforms. When available, file stores in direct I/O mode automatically load the native I/O
wlfileiodriver. This option tends to out-performCache-Flushand tend to be slower thanDirect-Write-With-Cache. This mode does not require a native storewlfileiodriver, but performs faster when they are available.Direct-Write-With-CacheStore records are written synchronously to primary files in the directory specified by the
Directoryattribute and asynchronously to a corresponding cache file in theCache Directory. TheCache Directoryprovides information about disk space, locking, security, and performance implications. This mode requires a native storewlfileiocodedriver. If the native driver cannot be loaded, then the write mode automatically switches toDirect-Write. See Cache Directory.Cache-FlushTransactions cannot complete until all of their writes have been flushed down to disk. This policy is reliable and scales well as the number of simultaneous users increases.Transactionally safe but tends to be a lower performer than direct-write policies.
DisabledTransactions are complete as soon as their writes are cached in memory, instead of waiting for the writes to successfully reach the disk. This is the fastest policy because write requests do not block waiting to be synchronized to disk, but, unlike other policies, is not transactionally safe in the event of operating system or hardware failures. Such failures can lead to duplicate or lost data/messages. This option does not require native store
wlfileiodrivers, but may run faster when they are available. Some non-WebLogic JMS vendors default to a policy that is equivalent toDisabled.Notes:
When available, file stores load WebLogic
wlfileionative drivers, which can improve performance. These drivers are included with Windows, Solaris, Linux, and AIX WebLogic installations.Certain older versions of Microsoft Windows may incorrectly report storage device synchronous write completion if the Windows default
Write Cache Enabledsetting is used. This violates the transactional semantics of transactional products (not specific to Oracle), including file stores configured with aDirect-Write(default) orDirect-Write-With-Cachepolicy, as a system crash or power failure can lead to a loss or a duplication of records/messages. One of the visible symptoms is that this problem may manifest itself in high persistent message/transaction throughput exceeding the physical capabilities of your storage device. You can address the problem by applying a Microsoft supplied patch, disabling the WindowsWrite Cache Enabledsetting, or by using a power-protected storage device. See http://support.microsoft.com/kb/281672 and http://support.microsoft.com/kb/332023.NFS storage note: On some operating systems, native driver memory-mapping is incompatible with NFS when files are locked. Stores with synchronous write policies
Direct-Write-With-Cacheor Disabled, and WebLogic JMS paging stores enhance performance by using the nativewlfileiodriver to perform memory-map operating system calls. When a store detects an incompatibility between NFS, file locking, and memory mapping, it automatically downgrades to conventional read/write system calls instead of memory mapping. For best performance, Oracle recommends investigating alternative NFS client drivers, configuring a non-NFS storage location, or in controlled environments and at your own risk, disabling the file locks (See Enable File Locking). For more information, see "Tuning the WebLogic Persistent Store" in Tuning Performance of Oracle WebLogic Server.MBean Attribute:
GenericFileStoreMBean.SynchronousWritePolicyTarget The server instances, clusters, or migratable targets defined in the current domain that are candidates for hosting a file store, JDBC store, or replicated store. If scoped to a Resource Group or Resource Group Template, the target is inherited from the Virtual Target.
When selecting a cluster, the store must be targeted to the same cluster as the JMS server. When selecting a migratable target, the store must be targeted it to the same migratable target as the migratable JMS server or SAF agent. As a best practice, a path service should use its own custom store and share the same target as the store.
MBean Attribute:
PersistentStoreMBean.TargetsScope Specifies if the file store is accessible within the domain, a partition, or a resource group template.
Directory The path name to the file system directory where the file store maintains its data files.
When targeting a file store to a migratable target, the store directory must be accessible from all candidate server members in the migratable target.
For highest availability, use either a SAN (Storage Area Network) or other reliable shared storage.
Use of NFS mounts is discouraged, but supported. Most NFS mounts are not transactionally safe by default, and, to ensure transactional correctness, need to be configured using your NFS vendor documentation in order to honor synchronous write requests.
For
SynchronousWritePolicyofDirect-Write-With-Cache, see Cache Directory.Additional O/S tuning may be required if the directory is hosted by Microsoft Windows, see Synchronous Write Policy for details.
MBean Attribute:
FileStoreMBean.DirectoryChanges take effect after you redeploy the module or restart the server.
Logical Name The name used by subsystems to refer to different stores on different servers using the same name.
For example, an EJB that uses the timer service may refer to its store using the logical name, and this name may be valid on multiple servers in the same cluster, even if each server has a store with a different physical name.
Multiple stores in the same domain or the same cluster may share the same logical name. However, a given logical name may not be assigned to more than one store on the same server.
MBean Attribute:
FileStoreMBean.LogicalNameCache Directory The location of the cache directory for
Direct-Write-With-Cache, ignored for other policies.When
Direct-Write-With-Cacheis specified as theSynchronousWritePolicy, cache files are created in addition to primary files (see Directory for the location of primary files). If a cache directory location is specified, the cache file path isCacheDirectory/WLStoreCache/StoreNameFileNum.DAT.cache. When specified, Oracle recommends using absolute paths, but if the directory location is a relative path, thenCacheDirectoryis created relative to the WebLogic Server instance's home directory. If "" orNullis specified, theCache Directoryis located in the current operating systemtempdirectory as determined by thejava.io.tmpdirJava System property (JDK's default:/tmpon UNIX,%TEMP%on Windows) and isTempDirectory/WLStoreCache/DomainName/unique-id/ StoreNameFileNum.DAT.cache. The value ofjava.io.tmpdirvaries between operating systems and configurations, and can be overridden by passing-Djava.io.tmpdir=My_pathon the JVM command line.Considerations:
Security: Some users may want to set specific directory permissions to limit access to the cache directory, especially if there are custom configured user access limitations on the primary directory. For a complete guide to WebLogic security, see "Securing a Production Environment for Oracle WebLogic Server."
Additional Disk Space Usage: Cache files consume the same amount of disk space as the primary store files that they mirror. See Directory for the location of primary store files.
Performance: For the best performance, a cache directory should be located in local storage instead of NAS/SAN (remote) storage, preferably in the operating system's
tempdirectory. Relative paths should be avoided, as relative paths are located based on the domain installation, which is typically on remote storage. It is safe to delete a cache directory while the store is not running, but this may slow down the next store boot.Preventing Corruption and File Locking: Two same named stores must not be configured to share the same primary or cache directory. There are store file locking checks that are designed to detect such conflicts and prevent corruption by failing the store boot, but it is not recommended to depend on the file locking feature for correctness. See Enable File Locking.
Boot Recovery: Cache files are reused to speed up the File Store boot and recovery process, but only if the store's host WebLogic Server instance has been shut down cleanly prior to the current boot. For example, cache files are not re-used and are instead fully recreated: after a
kill -9, after an OS or JVM crash, or after an off-line change to the primary files, such as a store admin compaction. When cache files are recreated, aWarninglog message 280102 is generated.Fail-Over/Migration Recovery: A file store safely recovers its data without its cache directory. Therefore, a cache directory does not need to be copied or otherwise made accessible after a fail-over or migration, and similarly does not need to be placed in NAS/SAN storage. A
Warninglog message 280102, which is generated to indicate the need to recreate the cache on the new host system, can be ignored.Cache File Cleanup: To prevent unused cache files from consuming disk space, test and developer environments should periodically delete cache files.
MBean Attribute:
FileStoreMBean.CacheDirectoryMinimum Window Buffer Size The minimum amount of data, in bytes and rounded down to the nearest power of 2, mapped into the JVM's address space per primary store file. Applies to synchronous write policies
Direct-Write-With-CacheandDisabled, but only when a nativewlfileiolibrary is loaded. See Maximum Window Buffer Size.MBean Attribute:
FileStoreMBean.MinWindowBufferSizeMinimum value:
-1Maximum value:
1073741824Maximum Window Buffer Size The maximum amount of data, in bytes and rounded down to the nearest power of 2, mapped into the JVM's address space per primary store file. Applies to synchronous write policies
Direct-Write-With-CacheandDisabledbut only when the nativewlfileiolibrary is loaded.A window buffer does not consume Java heap memory, but does consume off-heap (native) memory. If the store is unable to allocate the requested buffer size, it allocates smaller and smaller buffers until it reaches
MinWindowBufferSize, and then fails if cannot honorMinWindowBufferSize.Oracle recommends setting the max window buffer size to more than double the size of the largest write (multiple concurrently updated records may be combined into a single write), and greater than or equal to the file size, unless there are other constraints. 32-bit JVMs may impose a total limit of between 2 and 4GB for combined Java heap plus off-heap (native) memory usage.
See store attribute
AllocatedWindowBufferBytesto find out the actual allocated Window Buffer Size.MBean Attribute:
FileStoreMBean.MaxWindowBufferSizeMinimum value:
-1Maximum value:
1073741824IO Buffer Size The I/O buffer size, in bytes, automatically rounded down to the nearest power of 2.
For the
Direct-Write-With-Cachepolicy when a nativewlfileiodriver is available,IOBufferSizedescribes the maximum portion of a cache view that is passed to a system call. This portion does not consume off-heap (native) or Java heap memory.For the
Direct-WriteandCache-Flushpolicies,IOBufferSizeis the size of a per store buffer which consumes off-heap (native) memory, where one buffer is allocated during run-time, but multiple buffers may be temporarily created during boot recovery.When a native
wlfileiodriver is not available, the setting applies to off-heap (native) memory for all policies (includingDisabled).For the best runtime performance, Oracle recommends setting
IOBufferSizeso that it is larger than the largest write (multiple concurrent store requests may be combined into a single write).For the best boot recovery time performance of large stores, Oracle recommends setting
IOBufferSizeto at least 2 megabytes.See AllocatedIOBufferBytes to find out the actual allocated off-heap (native) memory amount. It is a multiple of
IOBufferSizefor theDirect-WriteandCache-Flushpolicies, or zero.MBean Attribute:
FileStoreMBean.IoBufferSizeMinimum value:
-1Maximum value:
67108864Maximum File Size The maximum file size, in bytes.
The
MaxFileSizevalue affects the number of files needed to accommodate a store of a particular size (number of files = store size/MaxFileSize rounded up).A file store automatically reuses space freed by deleted records and automatically expands individual files up to
MaxFileSizeif there is not enough space for a new record. If there is no space left in exiting files for a new record, a store creates an additional file.A small number of larger files is normally preferred over a large number of smaller files as each file allocates Window Buffer and file handles.
If
MaxFileSizeis larger than 2^24 *BlockSize, thenMaxFileSizeis ignored, and the value becomes 2^24 *BlockSize. The defaultBlockSizeis 512, and 2^24 * 512 is 8 GB.See Initial Size.
MBean Attribute:
FileStoreMBean.MaxFileSizeMinimum value:
1048576Maximum value:
2139095040Enable File Locking Determines whether OS file locking is used.
When file locking protection is enabled, a store boot fails if another store instance already has opened the store files. Do not disable this setting unless you have procedures in place to prevent multiple store instances from opening the same file. File locking is not required but helps prevent corruption in the event that two same-named file store instances attempt to operate in the same directories. This setting applies to both primary and cache files.
MBean Attribute:
FileStoreMBean.FileLockingEnabledBlock Size The smallest addressable block, in bytes, of a file. When a native
wlfileiodriver is available and the block size has not been configured by the user, the store selects the minimum OS specific value for unbuffered (direct) I/O, if it is within the range [512, 8192].A file store's block size does not change once the file store creates its files. Changes to block size only take effect for new file stores or after the current files have been deleted. See "Tuning the Persistent Store" in Tuning Performance of Oracle WebLogic Server.
MBean Attribute:
FileStoreMBean.BlockSizeMinimum value:
-1Maximum value:
8192Initial Size The initial file size, in bytes.
Set
InitialSizeto pre-allocate file space during a file store boot. IfInitialSizeexceedsMaxFileSize, a store creates multiple files (number of files =InitialSize/MaxFileSizerounded up).A file store automatically reuses the space from deleted records and automatically expands a file if there is not enough space for a new write request.
Use
InitialSizeto limit or prevent file expansions during runtime, as file expansion introduces temporary latencies that may be noticeable under rare circumstances.Changes to initial size only take effect for new file stores, or after any current files have been deleted prior to restart.
See Maximum File Size.
MBean Attribute:
FileStoreMBean.InitialSizeMinimum value:
0
|