E Installing OSM on Engineered Systems
This appendix describes recommendations for installing Oracle Communications Order and Service Management (OSM) on engineered systems.
JDBC Recommendations
This section includes recommendations for JDBC.
For engineered systems, Oracle recommends that you use SDP protocol over Infiniband (IB). This protocol enables multiple performance enhancements, such as input/output, thread management, and request handling efficiency. Typical steps to enable the SDP protocol include:
-
Ensure the physical Infiniband connection exists and is operational between the WebLogic server host and the database host.
-
Set up an SDP listener on the Infiniband network.
-
In the JDBC URL, replace TCP protocol with SDP protocol, and if necessary, change the port number to match the SDP listener's port. For example:
jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=SDP)(HOST=VIP_addr)(PORT=port))(CONNECT_DATA=(SERVICE_NAME=service_name) (INSTANCE_NAME=instance_name)))
-
Manually add the following system properties to the startWebLogic.sh or startManagedServer_xx.sh.
-Djava.net.preferIPv4Stack=true -Doracle.net.SDP=true
-
Initial Capacity: Oracle recommends setting this value to Max Capacity for production deployments to avoid shrinking and growing of the JDBC pool size. Setting the Initial Capacity value impacts available resources on both WebLogic server and database server by consuming additional resources at the start up time, and also lengthens the server start up time.
-
Max Capacity: Set this to a peak and sustainable value, which can be supported by both by WebLogic server (additional memory and processing) and the database server (session resources and concurrency). In uniform cluster deployments of JDBC connection pools to a cluster, the Max Capacity value applies to each WebLogic server node individually, not for the whole cluster. Set Max Capacity such that ((nodes x Max Capacity) <= sessions), where nodes is the number of nodes in the WebLogic Server cluster and sessions is the number of peak, concurrent, and safely sustainable sessions to the database server.
Note:
Max Capacity is an important parameter that requires iterative tuning based on scenario and workload. One approach is to set it to a high value for peak load tests, and monitor what percentage of it has been used, and then adjust the MaxCapacity to at least that high.
-
Statement Cache Size: The prepared statement cache size is used to keep a cache of compiled SQL statements in memory, thus improving the performance by avoiding repeated processing in the WebLogic server and database. For lightly used data sources, the default value of 10 is enough. For production systems, Oracle recommends a value of 30 to 40.
Note:
Each JDBC connection in the Connection Pool creates its own prepared statement cache. When you tune this parameter, consider the additional memory consumption demand caused by (steady size of Connection Pool x Prepared Statement Cache Size). A demand that is too high may cause "Out of Memory" exceptions on WebLogic server and may disable the connection pool altogether, rendering the server useless. Tuning Statement Cache Size is achieved by an iterative process, influenced by factors of the scenario, workload, and steady state size of the connection pool for the given data source.
SDP does not support Oracle Single Client Access Name (SCAN) addresses. It supports VIP addresses over InfiniBand. Please see the Oracle documentation for more instructions on configuring Engineered Systems with SDP.
Configuring Exalogic
The following sections provide recommendations for configuring the application layer.
Exalogic User Process Limit
Table E-1 shows the user process limit for Exalogic systems.
Table E-1 Exalogic User Process Limits
| Parameter | Value |
|---|---|
|
Core file size |
0 |
|
Data seg size |
Unlimited |
|
Scheduling priority |
0 |
|
File size |
Unlimited |
|
Pending signals |
774889 |
|
Max locked memory |
Unlimited |
|
Max memory size |
Unlimited |
|
Open files |
65536 |
|
Pipe size |
8 |
|
POSIX message queues |
819200 |
|
Real-time priority |
0 |
|
Stack size |
8192 |
|
CPU time |
Unlimited |
|
Max user processes |
774889 |
|
Virtual memory |
Unlimited |
|
File locks |
Unlimited |
Exalogic Kernel Parameters
Table E-2 shows the kernel parameters for Exalogic systems.
Table E-2 Exalogic Kernel Parameters
| Parameter | Value |
|---|---|
|
net.ipv4.ip_forward |
0 |
|
net.ipv4.conf.default.rp_filter |
2 |
|
net.ipv4.conf.default.accept_source_route |
0 |
|
kernel.sysrq |
0 |
|
kernel.core_uses_pid |
1 |
|
net.ipv4.tcp_syncookies |
1 |
|
kernel.msgmnb |
65536 |
|
kernel.msgmax |
65536 |
|
kernel.shmmax |
68 719 476 736 |
|
kernel.shmall |
4 294 967 296 |
|
net.ipv4.tcp_rmem |
16 777 216 16 777 216 16 777 216 |
|
net.ipv4.tcp_wmem |
16 777 216 16 777 216 16 777 216 |
|
net.ipv4.tcp_mem |
16 777 216 16 777 216 16 777 216 |
|
net.core.optmem_max |
16 777 216 |
|
net.core.rmem_max |
16 777 216 |
|
net.core.wmem_max |
16 777 216 |
|
net.core.rmem_default |
16 777 216 |
|
net.ipv4.ip_local_port_range |
9000 65500 |
|
vm.nr_hugepages |
10000 |
|
fs.file-max |
262144 |
|
net.core.netdev_max_backlog |
250000 |
|
net.ipv4.tcp_timestamps |
1 |
|
net.ipv4.tcp_window_scaling |
1 |
|
vm.dirty_background_ratio |
3 |
|
vm.min_free_kbytes |
1 048 576 |
|
net.ipv4.tcp_fin_timeout |
15 |
|
net.ipv4.tcp_keepalive_time |
120 |
|
net.core.somaxconn |
1024 |
|
net.ipv4.tcp_sack |
0 |
|
net.ipv4.tcp_dsack |
0 |
|
net.ipv4.tcp_keepalive_probes |
3 |
|
net.ipv4.tcp_keepalive_intvl |
30 |
OSM WebLogic Server Configuration
Table E-3 shows the WebLogic Server configuration.
Table E-3 OSM WebLogic Server Configuration
| Parameter | Value |
|---|---|
|
JTA Timeout |
600 seconds |
|
JMS Persistence Mechanism |
FileStore on SAN |
|
# of SAF Agents |
32: OSM |
|
JDBC: Initial Capacity |
64: OSM |
|
JDBC: Increment |
1 |
|
Statement Cache Size |
48: OSM |
|
Work Managers |
80: OSM oms.automation.core; 10: oms.xml |
|
Message Bridge Threads |
2 |
|
Accept backlog |
900 |
|
FileStore Write Policy |
Direct-Write-With-Cache |
|
JDBC: Max Capacity |
128: OSM |
|
JDBC: Shrink Frequency |
60 |
|
JDBC: Row Prefetch Size |
200 |
|
WLS: Native IO |
True |
|
Cluster Messaging Mode |
Multicast1 |
JVM Options
Table E-4 shows the Java virtual machine (JVM) options for an Exalogic system.
Table E-4 Exalogic JVM Options
| Parameter | Value |
|---|---|
|
64-bit packages |
Yes |
|
64 bit mode |
-d64 |
|
Production Mode |
True |
|
JVM HotSpot |
-server |
|
JVM: net IPv4 |
-Djava.net.preferIPv4Stack=true |
|
SDP |
-Doracle.net.SDP=true |
|
WLS: Sockets |
-Dweblogic.SocketReaders=16 |
|
WLS: Threads |
-Dweblogic.threadpool.MinPoolSize=300 |
Tuning the Oracle Database
For every Oracle Database installation, there are a number of init.ora (or spfile.ora) parameters that affect performance. Table E-5 lists important initialization parameters for use with OSM:
Table E-5 Suggested Oracle Database Parameters for Engineered Systems
| Parameter Name | Sparc SuperCluster (SSC) | Exadata |
|---|---|---|
|
db_writer_processes |
8 |
3 |
|
filesystemio_options |
'setall' |
'setall' |
|
processes |
5000 |
5000 |
|
sessions |
7680 |
7536 |
|
undo_retention |
1800 |
1800 |
|
deferred_segment_creation |
false |
false |
Note:
Oracle recommends that you use the default value for commit_wait and ensure that values for sga_max_size and sga_target for SSC are equal. This is to avoid major issues with the Solaris kernel.
Table E-6 suggests initial values for tuning parameters for the Oracle database.
Table E-6 Recommended Initial values of Oracle Database Parameters for Engineered Systems
| Parameter Name | Sparc SuperCluster (SSC) | Exadata |
|---|---|---|
|
memory_target |
134217728000 |
0 |
|
open_cursors |
15000 |
1000 |
|
pga_aggregate_target |
0 |
8589934592 |
|
sga_max_size |
77846282240 |
34359738368 |
|
sga_target |
77846282240 |
34359738368 |
For information about collecting more accurate database statistics, see the knowledge article about best practices for managing optimizer statistics [Doc ID 1662447.1], available from the Oracle support website:
Configuring Database Schema Partitioning
For detailed information about partitioning the database schema, see OSM System Administrator's Guide.
Multi-database Source Configuration Using N Oracle RAC Nodes
Oracle recommends that you use an Active-Active Oracle RAC database configuration to provide scalability and high availability for the database. For more information, see "Oracle RAC Database Active-Active Deployments."
Note:
OSM installer sets up only two active Oracle RAC nodes by default. For information about adding more nodes, see "Changing the WebLogic Server or Oracle RAC Database Size".
Database Storage
Recommendations for setting up database storage include the following:
-
Use Automatic Storage Management (ASM) for managing data disk storage.
-
For storage reliability, use Normal (two-way mirrored) Redundancy and ensure that the tablespace, data files, and redo logs are on this storage.
-
Place redo logs, which are sensitive to storage response time, should be put on storage with a service time of less than 5 ms.
-
Specify large redo log files to avoid frequent redo log switching. For redundancy, use a mirrored configuration for redo logs.
-
Finalize the requirements for latency and IOPS during your hardware sizing exercise.
Recommendations for configuring tablespaces include the following:
-
Use Automatic Segment Space Management (ASSM) for each tablespace.
-
Whenever disk space permits, use BIGFILE for tablespace creation. This simplifies the management of tablespace allocation by using a single data file for tablespace.
-
If you must use a SMALLFILE tablespace, plan for the possibility that a large number of data files might be created for OSM schema. Plan to implement a naming convention for data files and find an ideal location for data files that allows for future growth.