This appendix describes recommendations for installing Oracle Communications Order and Service Management (OSM) on engineered systems.
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 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.
If necessary, change the port number to match the SDP listener's port in the JDBC URL.
Manually add the system properties -Djava.net.preferIPv4Stack=true and -Doracle.net.SDP=true to the startWebLogic.sh script (or run startManagedServer_XX.sh).
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. Select the Max Capacity such that ((number of nodes in WebLogic server cluster X Max Capacity) <= 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 DataSources, the default value of 10 is sufficient.
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}). 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.The following sections provide recommendations for configuring the application layer.
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 |
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 |
Table E-3 shows the WebLogic Server configuration.
Table E-3 OSM WebLogic Server Configuration
Parameter | Value |
---|---|
JTA Timeout |
1200 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 |
For every Oracle Database installation, there are a number of init.ora (or spfile.ora) parameters that affect performance. The following table lists important init parameters for use with OSM:
Table E-5 Recommendations for init Parameters for Oracle Database
Parameter Name | Sparc SuperCluster (SSC) | Exadata |
---|---|---|
commit_wait |
transaction commit |
transaction commit |
db_block_size |
8192 |
8192 |
db_writer_processes |
8 |
3 |
filesystemio_options |
'setall' |
'setall' |
memory_max_target |
0 |
0 |
memory_target |
134217728000 |
0 |
O7_DICTIONARY_ACCESSIBILITY |
TRUE |
TRUE |
open_cursors |
15000 |
1000 |
pga_aggregate_target |
0 |
8589934592 |
processes |
5000 |
5000 |
sessions |
7680 |
7536 |
sga_max_size |
77846282240 |
34359738368 |
sga_target |
77846282240 |
34359738368 |
undo_retention |
1800 |
1800 |
deferred_segment_creation |
true |
true |
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.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:
For detailed information about partitioning the database schema, see OSM System Administrator's Guide.
Oracle recommends that you use an Active-Active Oracle RAC database configuration to provide scalability and high availability for the database. For more information about high availability and its impact on the database Oracle RAC, see Appendix B of OSM Installation Guide.
Note:
OSM installer sets up only two active Oracle RAC nodes, by default. For information about adding more nodes, see "Changing the WebLogic Server of Oracle RAC Database Size".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.