Release 9.0.2
Part Number A95192-01
 Home |
 Solution Area |
 Contents |
 Index |
| Oracle Internet Directory Administrator's Guide Release 9.0.2 Part Number A95192-01 |
|
Once you have completed capacity planning as described in Chapter 19, "Capacity Planning Considerations", and you have acquired the necessary hardware, then you must ensure that the combined hardware and software are yielding the desired levels of performance. This chapter gives guidelines for tuning an Oracle Internet Directory installation. It contains these topics:
The two main performance metrics for any installation of Oracle Internet Directory are:
This is the time for each operation to complete.
This is the rate at which an instance of Oracle Internet Directory is capable of completing client operations
If the performance tests yield poor results, the performance problems may be identified and fixed using the information provided in the following sections.
Knowledge of the following tools is recommended for Solaris and most other UNIX operating systems:
Knowledge of the following tools is recommended for Windows NT:
Knowledge of the following tools is recommended for Oracle9i:
In addition to the operating system tools, the LDAP applications being used in a customer environment must be able to provide latency and throughput measurement.
In addition, the Database Statistics Collection Tool (oidstats.sh), located at $ORACLE_HOME/ldap/admin, is provided to analyze the various database 'ods' schema objects to estimate the statistics.
|
Note: To run shell script tools on the Windows operating system, you need one of the following UNIX emulation utilities:
|
The CPU is perhaps the most important resource available for any software. While Chapter 19, "Capacity Planning Considerations" gives a rough estimate of the required CPU horsepower for a given application load, sometimes insufficient tuning can cause inefficient use of the CPU resources. Consider tuning CPU resources if either of the following cases is true:
Internal benchmarks show that Oracle Internet Directory performs best when approximately 70 to 75 percent of the CPU resources are consumed by Oracle Internet Directory processes, and the remaining (about 25 to 30 percent) are consumed by the Oracle foreground processes corresponding to the database connections. While monitoring CPU usage, it is also important to monitor the percentage of time spent in the system space compared to user space. Internal benchmarks show best throughput numbers at about 85 percent user and 15 percent system time.
This section contains these topics:
The demands placed by Oracle Internet Directory processes on the CPU can be controlled by the ORCLSERVERPROCS and ORCLMAXCC parameters. This table lists suggested values for these parameters for various client loads:
If we take the example of 500 concurrent clients, a value of 4 for ORCLSERVERPROCS with a value of 10 for ORCLMAXCC will result in the following configuration:
Oracle Internet Directory scales very well with CPU resources both with respect to the throughput of operations and concurrency of clients. From the above table, say we have a 4 CPU box and are able to maintain a peak throughput of 'p' operations per second for a concurrency of 'n' clients.
With additional number of CPUs or with faster CPUs, we can achieve either or both of the following benefits:
If the CPU usage at peak loads is not at 100 percent and the system is idle for a large percentage of the time (that is, more than 5 percent), this indicates that Oracle Internet Directory processes are under-configured and are not making the best utilization of the CPU resources. To solve this problem, one must systematically increase the values of ORCLSERVERPROCS and ORCLMAXCC until the CPU utilization reaches 100 percent and the system and user time are split up as follows:
Tuning of CPU resources for Oracle Foreground processes should be considered only if both of the following conditions are met:
If Oracle foreground processes are consuming excessive CPU, it implies that the queries that Oracle Internet Directory is making against the database are using too many CPU cycles. Although there is very little control available to the users on the types of underlying operations performed by the database, the following should be attempted:
$ORACLE_HOME/ldap/admin/oidstats.sh can be used to collect statistics.
To run shell script tools on the Windows operating system, you need one of the following UNIX emulation utilities:
Note:
Several Symmetric Multi-Processor (SMP) systems offer the capability to bind a particular process to a particular CPU. While it is generally a good idea not to bind any process to any processor, it may improve performance if the following conditions are met:
In internal benchmarks, it has been observed that binding the OID Server process and its associated Oracle shadow processes to the same CPU generally gives the best performance.
If none of the tips stated in the preceding sections solve CPU related performance problems, the following options are available:
After the CPU, memory is the next most important thing to tune. The primary consumer of memory in an Oracle Internet Directory installation is the Oracle9i database. Make the SGA of the back-end database large enough while leaving room for Oracle Internet Directory and Oracle processes to operate their private stacks and heaps. This section provides some details on determining various components of the SGA.
This section contains these topics:
The SGA should be sized based on the available physical memory on the system running Oracle9i.
Once the available size of the SGA is determined, two primary tuning items need to be considered:
An initial estimate for the shared pool size is .5 MB per concurrent database connection determined above.
If this estimate consumes more than 30 percent of the total SGA, use 30 percent of the total SGA instead.
Divide 60 percent of the remaining available SGA size by the block size for the database and use this value for the number of DB_BLOCK_BUFFERS. Both of these values should be initial estimates and can be refined using BSTAT/ESTAT and other RDBMS monitoring tools to determine more accurate sizes for best performance.
If there is insufficient memory to run both the database and the Oracle directory server on the same computer, then one can put the database on a different computer.
Balancing Disk I/O is an important consideration in overall RDBMS, and hence Oracle Internet Directory performance. Typically, one can maximize the I/O throughput by using one or more of the following techniques:
This section contains these topics:
The Oracle Internet Directory schema is distributed among several tablespaces at installation time for ease of maintenance and performance. Each tablespace contains a grouping of Oracle Internet Directory schema objects appropriate for co-location on disk storage. As available, it is also beneficial to distribute the following objects onto separate logical disks.
|
See Also:
"RAID" for more discussion about logical disks |
Separate the following:
Separating the attribute store table from its index
Separating the DN catalog from its index
(Empirically, separate the storage tablespace from the associated index)
Alternating the attribute store and DN catalog indexes. This helps even if there are only two logical disks available (one containing OLTS_CT_DN and OLTS_IND_ATTRSTORE and the other containing OLTS_IND_CT_DN and OLTS_ATTRSTORE)
The information on balancing tablespaces is given in terms of separating Oracle Internet Directory tablespaces onto different logical drives. This assumes that a 'logical drive' is manifested on a separate disk or set of disks from other 'logical drives', and thus represents a division among disks for I/O. (Two logical drives on the same physical disk media do not really provide the same combined I/O throughput of two logical drives located on different physical media.) If a logical drive can be manifest on a striped or RAID disk subsystem, then this may increase the I/O capacity of that logical drive. However, the tablespace locations considered earlier remain applicable when considering, for instance, different logical drives of a volume manager.
This section describes the other tunable parameters available to an Oracle Internet Directory installation.
The following table gives a quick overview of the recommended values of RDBMS parameters for various client loads. These parameters are configurable in the initialization parameter file.
This section describes each of the RDBMS tunable parameters in more detail. It contains these topics:
Configure the OPEN_CURSORS parameter as follows:
OPEN_CURSORS=200
The Oracle9i default of 50 or so is too small to accommodate Oracle Internet Directory server cursor cache. Note that this value is not dependent on other Oracle Internet Directory server parameters, such as # SERVERS and # WORKERS. The value of 200 is sufficient for any size DIT.
Configure the SESSIONS parameter as follows:
PROCESSES = (# OID server processes per instance) x(# DB Connections per server + 1) x (# of OID instances) + 20 SESSIONS = 1.1 * PROCESSES + 5
Each Oracle Internet Directory server process requires a number of concurrent database connections equal to the number of worker threads configured for that server plus one. The total number of concurrent database connections allowed must therefore include this number per server, per instance. The additional 20 connections added to the parameter value accounts for the Oracle background processes plus other Oracle Internet Directory processes such as OID Monitor, OID Control, Oracle directory replication server, and bulk tools.
Depending on the total number of concurrent database connections required, and as determined by the setting for the SESSIONS parameter, enabling shared server process may help balance overall system load better. If the total number of concurrent database connections required is over 300, then configure the shared server. One shared server should be configured for every 10 database connections required.
The main parameters that contribute to the SGA are discussed in "Memory Tuning". The following are a few more parameters that may be tuned:
Set to 262144 (256k) to ensure sufficient sort area available to prevent on-disk sorts.
Set to 32768 (32k) as an initial estimate. If log write performance becomes a performance problem, use a large enough value to make sure (redo log space requests / redo entries) > 1/5000 to prevent the LGWR process from falling behind. This overall has little size effect on the variable SGA size, so making this a little bit too large should not be a problem.
In the current release of OID, the OID server entry cache is supported only in the single server OID instance. The benefits of entry caching are maximized when the entry cache hit ratio is very high. It is recommended that the entry cache be used for small- to medium-sized directory deployments where two criteria are met:
Internal benchmarks have indicated that for directory deployments where the working set of entries is a few hundred thousand entries, the entry cache doubled the throughput of operations for up to 1000 concurrent clients.
For larger directory deployments involving a larger working set of directory entries and a higher concurrency of clients, the multi-process OID server instance and the Oracle buffer cache proves to be the scalable architecture of choice for performance.
This section gives some quick pointers for common performance related problems.
If LDAP search performance is poor, make sure that:
ODS user is ANALYZED
For searches involving multiple filter operands, make sure that the order in which they are given goes from the most specific to the least specific. For example, &(l=Chicago)(state=Illinois)(c=US) is better than &(c=US)(state=Illinois)(l=Chicago).
If LDAP add or modify performance is poor, make sure that:
ODS user is ANALYZED
You can also use the OID Database Statistics Collection tool to analyze the various database ods schema objects to estimate the statistics.
|
See Also:
"OID Database Statistics Collection Tool Syntax" for instructions on using the OID Database Statistics Collection tool |
|
 Copyright © 1999, 2002 Oracle Corporation. All Rights Reserved. |
|