Tuning the WebLogic Persistent Store 8-13
1. If necessary, click Lock Edit in the Change Center upper left corner of the
Administration Console to get an Edit lock for the domain.
2. In the Domain Structure tree, expand the Diagnostics node and select Archives.
3. In the Summary of Diagnostic Archives list, select the server name of the archive
that you want to modify.
4. On the Settings for [server_name] page, deselect the Diagnostic Store File
Locking Enabled check box.
5. Click Save to save the changes. If necessary, click Activate Changes in the Change
Center.
6.
Restart the server you modified for the changes to take effect. The resulting config.xml entry looks like:
Example 8–6 Example config.xml Entry for Disabling File Locking for a Diagnostics File
Store
server nameexamplesServername
... server-diagnostic-config
diagnostic-store-dirdatastorediagnosticsdiagnostic-store-dir diagnostic-store-file-locking-enabledfalsediagnostic-store-file-lockingenabled
diagnostic-data-archive-typeFileStoreArchivediagnostic-data-archive-type data-retirement-enabledtruedata-retirement-enabled
preferred-store-size-limit100preferred-store-size-limit store-size-check-period1store-size-check-period
server-diagnostic-config server
8-14 Performance and Tuning for Oracle WebLogic Server
9
DataBase Tuning 9-1
9
DataBase Tuning
Your database can be a major enterprise-level bottleneck. Configure your database for optimal performance by following the tuning guidelines in this section and in the
product documentation for the database you are using.
■
Section 9.1, General Suggestions
■
Section 9.2, Database-Specific Tuning
9.1 General Suggestions
This section provides general database tuning suggestions:
■
Good database design — Distribute the database workload across multiple disks to avoid or reduce disk overloading. Good design also includes proper sizing and
organization of tables, indexes, and logs.
■
Disk IO optimization — Disk IO optimization is related directly to throughput and scalability. Access to even the fastest disk is orders of magnitude slower than
memory access. Whenever possible, optimize the number of disk accesses. In general, selecting a larger blockbuffer size for IO reduces the number of disk
accesses and might substantially increase throughput in a heavily loaded production environment.
■
Checkpointing — This mechanism periodically flushes all dirty cache data to disk, which increases the IO activity and system resource usage for the duration of the
checkpoint. Although frequent checkpointing can increase the consistency of on-disk data, it can also slow database performance. Most database systems have
checkpointing capability, but not all database systems provide user-level controls. Oracle, for example, allows administrators to set the frequency of checkpoints
while users have no control over SQLServer 7.x checkpoints. For recommended settings, see the product documentation for the database you are using.
■
Disk and database overhead can sometimes be dramatically reduced by batching multiple operations together andor increasing the number of operations that run
in parallel increasing concurrency. Examples:
–
Increasing the value of the Message bridge BatchSize or the Store-and-Forward WindowSize can improve performance as larger batch
sizes produce fewer but larger IOs.
–
Programmatically leveraging JDBCs batch APIs.
–
Use the MDB transaction batching feature. See Chapter 11, Tuning
Message-Driven Beans .
