21 Tuning Considerations for the Directory

21.3.1 Tuning CPU for Oracle Internet Directory Processes

The demands placed by Oracle Internet Directory processes on the CPU can be controlled by the ORCLSERVERPROCS and ORCLMAXCC parameters. Table 21-1 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:

• There will be four server processes created.

• Each server process will spawn 10 worker threads that will do the actual work.

• Each server process will also maintain a pool of sixteen database connections (10+5+1) that will be shared among the worker threads.

Oracle Internet Directory scales very well with CPU resources both with respect to the throughput of operations and concurrency of clients. From the previous table, say we have a 4 CPU box and are able to maintain a peak throughput of 'p' operations every 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:

• Achieve a thoughput higher than 'p' for the same concurrency of 'n' clients

• Maintain the same 'p' operations throughput for a concurrency higher than 'n'

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:

• User time: 85 percent or higher

• System time: 15 percent or lower

21.3.2 Tuning CPU for Oracle Foreground Processes

Tuning of CPU resources for Oracle Foreground processes should be considered only if both of the following conditions are met:

• The CPU usage is close to 100 percent at peak loads.

• Oracle foreground processes consume more than 30 percent of all available CPU resources.

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:

• Database statistics on all of the tables and indexes associated with the ODS user on the database must be collected using the ANALYZE command. This helps the cost-based optimizer make better execution plans for the queries generated by Oracle Internet Directory. $ORACLE_HOME/ldap/admin/oidstats.sql can be used to collect statistics.

• If the ANALYZE fails to produce better results, and the LDAP queries used have a lot of filters in them, then a simple reorganization of the order in which the filters are specified (with the most specific filter in the beginning and the most generic filter at the end) helps reduce the CPU consumption of the Oracle foreground processes.

  
  

  Note: To run shell script tools on the Windows operating system, you need one of the following UNIX emulation utilities: Cygwin 1.3.2.2-1 or later. Visit: http://sources.redhat.com MKS Toolkit 8.6 or later. Visit: http://www.datafocus.com/

  
  

21.3.3 Taking Advantage of Processor Affinity on SMP Systems

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:

• The CPU utilization of the entire system is close to 100 percent.

• There are more than two CPUs on the computer.

In internal benchmarks, it has been observed that binding the Oracle Internet Directory Server process and its associated Oracle shadow processes to the same CPU generally gives the best performance.

21.3.4 Other Alternatives for a CPU Constrained System

If none of the tips stated in the preceding sections solve CPU related performance problems, the following options are available:

• Upgrade the processing power of the computer, that is, add more CPUs or replace slower CPUs with faster ones.

• Keep the Oracle directory server and the associated Oracle Database on separate computers.

21.4.1 Tuning the System Global Area (SGA) for the Oracle Database

The SGA should be sized based on the available physical memory on the system running the Oracle Database.

Once the available size of the SGA is determined, two primary tuning items need to be considered:

• Size of the shared pool

• Size of the buffer cache

An initial estimate for the shared pool size is.5 MB for each concurrent database connection previously determined.

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.

21.4.2 Other Alternatives for a Memory-Constrained System

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.

21.6.1 Required Parameters

Configure the OPEN_CURSORS parameter as follows:

OPEN_CURSORS=200

The Oracle Database 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.

Oracle Internet Directory replication depends on database replication. If you are using Oracle Internet Directory replication, configure the JOB_QUEUE_PROCESSES and PARALLEL_MIN_SERVERS database parameter to 1 or greater. For example:

JOB_QUEUE_PROCESSES=1
PARALLEL_MIN_SERVERS=1

21.6.2 Parameters Dependent on Oracle Internet Directory Server Configuration

Configure the SESSIONS parameter as follows:

PROCESSES = (# OID server processes for each instance) x 
            (# DB Connections for each 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 for each server, for each 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.

21.6.3 SGA Parameters Dependent on Hardware Resources

The main parameters that contribute to the SGA are discussed in "Memory Tuning". The following are a few more parameters that may be tuned:

• Sort area

  Set to 262144 (256k) to ensure sufficient sort area available to prevent sorts on disk.

• Redo Log Buffers

  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.

21.8.1 Optimizing Searches for Large Group Entries

Searches for group entries with several thousand attribute values for either the member or uniquemember attribute can have high latency. If you find unacceptably high latency in searches for large group entries with attributes other than member and uniquemember, then do the following:

1. If you do not need to retrieve all the attributes of the group entry, specify required attributes in the search request to optimize the latency.

2. If you still see unacceptable latency, even with required attributes specified, try re-creating the index EI_ATTRSTORE.

   1. Stop the Oracle Internet Directory instance.

   2. Log in to the Oracle Internet Directory database as the ODS user and execute the following query:

      DROP INDEX EI_ATTRSTORE;
      
      CREATE BITMAP INDEX EI_ATTRSTORE ON
      DS_ATTRSTORE(ENTRYID,ATTRNAME)
      TABLESPACE OLTS_ATTRSTORE
      PARALLEL COMPUTE STATISTICS NOLOGGING;
      
      

   3. Start the Oracle Internet Directory instance.

   Employ this method carefully and only when required, as re-creating EI_ATTRSTORE in this fashion may degrade the performance of typical messaging search operations by 5-10%.

21.8.2 Optimizing Searches for Skewed Attributes

To service a typical search request, the directory server sends a SQL statement to the Oracle Database. If a given attribute has very different response times depending on its value, then the attribute is said to be skewed. For example, if searches for my_attribute=value1 and my_attribute=value2 have very different response times, then my_attribute is said to be a skewed.

You can uniform the response times for searches for such an attribute by adding it as a value of the orclskewedattribute attribute, which is in the dsaconfig entry. The DN of the dsaconfig entry is cn=dsaconfig,cn=configsets,cn=oracle internet directory.

By default, the objectclass attribute is listed as a value in the orclskewedattribute attribute.

ldapmodify –D "cn=orcladmin" –w password -h host -p port <<!
dn: cn=dsaconfig,cn=configsets,cn=oracle internet directory
changetype: modify
add: orclskewedattribute
orclskewedattribute: my_attribute
!

21.9.1 Setting the Time Limit Mode by Using Oracle Directory Manager

To set the time limit mode:

1. In the navigator pane, expand Oracle Internet Directory Servers and select the directory server instance.

2. In the right pane, select the Query Optimization tab.

3. In the Query Optimization tab page, in the Time Limit Mode field, select either Accurate or Approximate.

4. Choose Apply.

21.9.2 Setting the Time Limit Mode by Using ldapmodify

To specify the search time limit mode to be either accurate or approximate, you set the orcltlimitmode attribute. A value of 0 is accurate, and a value of 1 is approximate. The default value is 1.