| Oracle® Mobile Collaboration Administrator's Guide 10g Release 1 (10.1.1) Part Number B14497-02 |
|
|
View PDF |
| Oracle® Mobile Collaboration Administrator's Guide 10g Release 1 (10.1.1) Part Number B14497-02 |
|
|
View PDF |
This appendix, through the following sections, discusses the tuning methods that enable you to optimize Oracle Collaboration Suite 10g Mobile Collaboration.
Upon installation, Oracle Collaboration Suite 10g Mobile Collaboration initializes a default setup that is appropriate for the performance of most applications. However, you may need to use additional tuning knobs to adjust performance, since applications vary in features, hardware setup, and performance requirements.
This section describes how to optimize the database for Oracle Mobile Collaboration. Topics include:
Use the ALTER SYSTEM statement and the SET clause to set the values for the processes and sessions, the automatic shared memory management feature of the System Global Area (sga_target), and PGA memory management (pga_aggregate) as follows:
alter system set processes=600 scope=spfile; alter system set sessions=700 scope=spfile; alter system set sga_target=1600M scope=spfile; alter system set pga_aggregate_target=1000M scope=spfile;
Because all of these statements use the SCOPE = SPFILE, the changes dictated by these statements apply only to the server parameter file. For more information on SPFILE, see Oracle Database Administrator's Guide. The changes to the SPFILE become effective at the next startup.
Adding redo log groups avoids failures from redo log switches. To perform the operations in this section, you must be granted the ALTER DATABASE system privilege. For more information on managing redo logs, see Oracle Database Administrator's Guide.
To add a redo log group, first use the query SELECT * FROM V$LOGFILE; to view the current active redo log files in the database. There are three redo log groups. Each group has two members, each sized 10M. You must add six additional redo log groups, for a total for nine redo log groups. In addition, each redo log group has two members, both sized 50M.
Note:
To illustrate these instructions, the redo log groups are referred to as redo log group 1 through redo log group 9. Redo log groups 1 through 3 are the initial redo log groups; redo log groups 4 through 9 are the additional groups.To add redo log group and its members, use the ALTER DATABASE with the ADD LOGFILE clause for each redo log group. The following statement adds redo log group 4 (o1_mf_4.log) to the database:
ALTER DATABASE
ADD LOGFILE GROUP 4 ('/home/ocs1/CS10Gm6b/oradata/CS10M6B/onlinelog/o1_mf_4.log','/home/ocs1/CS10Gm6b/backend/flash_recovery_area/CS10M6B/onlinelog/o1_mf_4.log')
SIZE 500K;
Notes:
Because the path of the redo log files varies, use the query result of the SELECT * FROM V$LOGFILE; to find the path locations of the members.
Use the fully specified filenames of new log members to indicate where the operating system file should be created. Otherwise, the files will be created in either the default or current directory of the database server, depending on the operating system.
After you complete creating the remainder of the redo log groups, you must then drop the first three redo log groups and their members. Before you can drop these groups, however, use the query result of SELECT * FROM V$LOG; to ensure that none of these groups are active (required for instance recovery) or current (the Log Writer, LGWR, is actively writing to this log). If any of the logs are active or current, then you must force a log switch to make log inactive using the ALTER SYSTEM statement with the SWITCH LOGFILE clause. If archiving is enabled, then you must ensure that a redo log group is archived before you drop it by viewing the query result of the V$LOG view.
Once redo log groups 1 through 3 are inactive, you can drop them using the ALTER DATABASE SQL statement with the DROP LOGFILE clause. For redo log groups 1 through 3, use the following statements:
ALTER DATABASE DROP LOGFILE GROUP 1; ALTER DATABASE DROP LOGFILE GROUP 2; ALTER DATABASE DROP LOGFILE GROUP 3;
Dropping redo log groups 1 through 3 leaves six redo log groups. Each group has two members, both sized 50 MB.
Oracle Application Server uses database connections for Single Sign-on (SSO). Because the default number of connections may not suffice for the high number of users, you should therefore increase the maxConnectionsInPool and cacheSize parameters of the policy.properties file ($ORACLE_HOME/sso/conf/policy.properties) to the following values:
maxConnectionsInPool = 300cacheSize = -1
Increasing the maximum number of connections for the JDBC and OID connection pools improves performance. You can increase this attribute by editing the parameters in the JDBC, OID Connection Pool page (accessed from the Site Administration page of the OracleAS Wireless System Manager). For more information, see "The OracleAS Wireless System Manager" and Oracle Application Server Wireless Administrator's Guide
Note:
The default number of maximum connections to the JDBC connection pool is 100.This section includes the following topics:
To tune the OC4J_Wireless Server instance to both enable the OC4J logs and to optimize the Java GC (garbage collection) attributes, you must modify both the OC4J Options and the Java attributes in the Java Options field, which are located in the Command Line Options section of the Oracle Enterprise Manger's Server Properties page (Figure D-1).
Note:
To access this page, first select the OC4J_Wireless process on the Home page and then select Administration. Next, select Server Properties (located under Instance Properties). The Server Properties page appears.Figure D-1 Editing the OC4J and Java Options
To enable OC4J logging, add the following to the OC4J_Options field:
-properties -userThreads -verbosity 10 -out oc4j.out -err oc4j.err
To optimize the Java GC options, add the following to the Java Options field:
-Xss256k -Xms512m -XMX1024m -XX+UseParallelGC -XXParallelGCThreads=4 -XX:NewRatio=2 -XX:SurvivorRatio=16 -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps
For more information on modifying the default GC behavior and improving GC performance, see Oracle Application Server Wireless Administrator's Guide.
Set the database driver as a thin driver by setting db.driver=thin in the System.Properties file ($ORACLE_HOME/wireless/server/classes/oracle/panama/core/System.properties).
Edit the following configuration directives in httdp.conf to enhance performance of the Oracle HTTP Server (OHS). See Oracle Application Server Wireless Administrator's Guide for descriptions of these directives. See Oracle Application Server Administrator's Guide for more information on accessing the httdp.conf file from the Oracle Collaboration Suite Enterprise Manager Application Server Control.
Backend Settings
MaxClients 300
MaxRequestsPerChild 0
Min SpareServers 5
MaxSpareServers 20
StartServers 5
Timeout 300
KeepAlive On
Application Tier Settings
MaxClients 300
MaxRequestsPerChild 0
MaxSpareServers 20
StartServers 5
Timeout 300
KeepAlive Off
The Web Cache capacity should be set to a high value depending upon the load. For example, if you are hitting 50 requests per second, then you must set the capacity to 100. You can increase the Web Cache capacity by editing the properties of the Web Cache's origin server.
To edit the Web Cache capacity from the Oracle Collaboration Suite Enterprise Manager Application Server Control:
Click Web Cache in the Application Server Home page of the Enterprise Manager. The Web Cache Home page appears.
Click the Administration tab.
Click Origin Servers (located in the Application section under Properties). The Origin Server page appears.
Select an origin server and then click Edit. The Edit Origin Server page appears.
Increase the value in the Capacity field.
Click OK to commit the change.
Note:
Depending on the incoming requests and the size of documents to be cached, you must also change the maximum incoming connections and the maximum cache size. You can change these values using the Resource Limits and Timeouts page (accessed by clicking Resource Limits and Timeouts in the Web Cache section of the Web Cache Administration tab).You can increase the values for the CAPACITY and RESOURCELIMITS parameters of the webache.xml file ($ORACLE_HOME/webcache/webcache.xml) if the values are not high enough. Change these parameters in webcache.xml on the Application tier (where the ORACLE HOME and HOST attributes of the CACHENAME element reflects the Application tier, such as <CACHE NAME="fstlc07d.us.oracle.com-WebCache" ORACLEHOME="/home/ocs1/CS10gm9b/midtier" HOSTNAME="fstlc07d.us.oracle.com" VOTES="1" CAPACITY="30" WCDEBUGON="NO">>) as follows:
Open the webcache.xml file.
Locate the CAPACITY parameter. You can set the value of this element as high as the value set for MaxClient in the httdp.conf file. For example, you can set this value to 300 servers. For more information, see "Optimizing the Performance of the Oracle HTTP Server".
Locate the <RESOURCELIMITS> parameter and then set the value of its MAXINBOUNDCONNECTIONS attribute to 700 and the MAXCAHESIZE attribute to 500 as follows:
<RESOURCELIMITS MAXINBOUNDCONNECTIONS="700" MAXCACHESIZE_MB="500"/>
Note:
You can further increase the values of these attributes if needed.See Oracle Application Server Webcache Administrator's Guide for more information on webcache.xml.
To optimize Oracle Mobile Access Mail, add the following lines to oc4j.properties ($ORACLE_HOME/j2ee/OC4J_Wireless/config/oc4j.properties):
oracle.ocs.ldappool.maxsize=300oracle.ocs.ldappool.minsize=5oracle.ocs.ldappool.shrinkinterval=1800oracle.ocs.ldappool.timeoutinterval=30oracle.ocs.ldappool.incrementsize=1oracle.ocs.ldappool.reconnecttime=30oracle.ocs.ldappool.initialsize=5oracle.mail.sdk.esmail.connpool_max_limit=100oracle.mail.sdk.esmail.connpool_min_limit=5oracle.mail.sdk.esmail.ojma_debug=falseoracle.mail.sdk.esmail.cache_inactivity_timeout=300oracle.mail.sdk.esmail.ldap_debug=falseoracle.mail.sdk.esmail.driver_type=thinoracle.mail.sdk.esmail.timing=falseoracle.mail.sdk.esmail.dbpool_timing=false
