Skip Headers
Oracle Internet Directory Administrator's Guide
10g (10.1.4.0.1)

Part Number B15991-01
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

25 Tuning Considerations for the Directory

Once you have completed capacity planning as described in Chapter 24, "Capacity Planning for the Directory", 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:

25.1 About Tuning

The two main performance metrics for any installation of Oracle Internet Directory are:

If the performance tests yield poor results, the performance problems may be identified and fixed using the information provided in the following sections.

25.2 Tools for Performance Tuning

Knowledge of the following tools is recommended for Solaris and most other UNIX operating systems:

Tool Description
top Displays the top CPU consumers on a system
vmstat Shows running statistics on various parts of the system including the Virtual Memory Manager
mpstat Shows an output similar to vmstat but split across various CPUs in the system. This is available on Solaris only.
iostat Shows the disk I/O statistics from various disk controllers

Knowledge of the following tools is recommended for Microsoft Windows:

Tool Description
Windows Performance Monitor Provides a customized view of the events in the system
Windows Task Manager Provides a high level output (like top on UNIX) of the major things happening in the system.

Knowledge of the following tools is recommended for the Oracle Database:

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.sql), located at $ORACLE_HOME/ldap/admin, is provided to analyze the various database 'ods' schema objects to estimate the statistics.


See Also:

The oidstats.sql command-line tool reference in Oracle Identity Management User Reference

25.3 CPU Usage Tuning

The CPU is perhaps the most important resource available for any software. While Chapter 24, "Capacity Planning for the Directory" 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:

25.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 25-1 lists suggested values for these parameters for various client loads.

Table 25-1 Suggested Values for ORCLSERVERPROCS and ORCLMAXCC Parameters

ORCLSERVERPROCS ORCLMAXCC # Concurrent clients supported without degrading throughput of operations # Clients supported without dropping connections Required # of CPUs

1

2

40


1

2

10

400

800

2

4

10

800

1600

4

8

10

1600

3200

8


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

25.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.

25.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.

25.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.

25.4 Memory Tuning

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 Oracle 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:

25.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.


See Also:

Oracle Database Performance Tuning Guide in the Oracle Database Documentation Library for more information on determining appropriate sizes for the SGA. This book tells how to ensure that the SGA size does not cause increased paging swapping activity. The latter is very detrimental to performance.

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.

25.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.

25.4.3 Tuning Security Event Tracking

The DSA configuration attributes orcloptracknumelemcontainers and orcloptrackmaxtotalsize control how much memory is used for security event tracking.

25.4.3.1 Tuning Memory Allocated for Event Tracking

The DSA configuration set attribute orcloptracknumelemcontainers allows you to choose the number of in-memory cache containers to be allocated for security event tracking in the Oracle Internet Directory server. There are two subtypes for this attribute. They are 1stlevel and 2ndlevel. The 1stlevel subtype is for setting the number of in-memory cache containers for storing information about users performing operations. The 2ndlevel subtype, which is applicable only to compare operation, sets the number of in-memory cache containers for information about the users whose userpassword is compared and tracked when detailed compare operation statistics is programmed.

The default value of both subtypes is 255. The appropriate values for these subtypes depend on the number of users in your environment and the number of applications used to access the directory, as follows:

  • In a deployment where several applications perform operations on behalf of a large number of end users, set 1stlevel proportional to the number of applications, plus a few hundred more for end users directly accessing the directory. Then set 2ndlevel proportional to the number of end users.

  • In a deployment where end users themselves perform the operations, set 1stlevel proportional to the number of end users, then set 2ndlevel to a small value, such as 25.

  • A typical proportional value is one fifth. Proportions between one tenth and one half are reasonable in most environments.

If your deployment requires it, set the values for orcloptracknumelemcontainers only when security events collection is turned on.


Note:

After you configure the value for 1stlevel only or values for both subtypes, security event information for one cycle of the next statistics periodicity will not be collected.

25.4.3.2 Tuning Memory Used for Each Operation

The DSA configuration attribute orcloptrackmaxtotalsize specifies the maximum number of bytes of RAM that security events tracking can use for each type of operation. Once the directory server exceeds this limit for information collected for an operation, the server stops collecting new information and records appropriate messages in server log files. For the compare operation, the directory server uses twice the value of the attribute, which is the combined amount of information about users performing compare operation and users whose passwords are being compared. The default value of orcloptrackmaxtotalsize is 100MB, which should be sufficient for most deployments. It can be increased to 200MB.

25.5 Disk Tuning

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:

25.6 Database Tuning

This section describes the other tunable parameters available to an Oracle Internet Directory installation.

Table 25-2 gives a quick overview of the recommended values of RDBMS parameters for various client loads. These parameters are configurable in the initialization parameter file.

Table 25-2 Recommended RDBMS Values for Various Client Loads

Parameters 500 Concurrent LDAP Clients 1000 Concurrent LDAP Clients 1500 Concurrent LDAP Clients 2000 Concurrent LDAP Clients

Open_cursors

200

200

200

200

Sessions

225

600

800

1200

Database_block_buffers

200 to 250 MB

200 to 250 MB

200 to 250 MB

200 to 250 MB

Database_block_size

8192

8192

8192

8192

Shared_pool_size

30 to 40 MB

30 to 40 MB

30 to 40 MB

30 to 40 MB

Processes

400

800

1000

1500


This section describes each of the RDBMS tunable parameters in more detail. It contains these topics:

25.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

In Oracle Internet Directory 10g (10.1.4.0.1), the absolute minimum value you can use for Database_block_size is 4 KB.

25.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.

25.6.2.1 Using Shared Server Process

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.


Note:

The number of required concurrent database connections depends on the hardware selected. See Oracle Database Net Services Administrator's Guide and Oracle Database Administrator's Guide, both in the Oracle Database Documentation Library, for further information about the shared server configuration.


25.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.

25.7 Entry Caching

In Oracle Internet Directory, 10g (10.1.4.0.1), the directory server entry cache is supported only in the single directory server instance. The benefits of entry caching are maximized when the entry cache hit ratio is very high. Oracle Corporation recommends that the entry cache be used for small-to-medium-sized directory deployments where:

Internal benchmarks indicate that, for directory deployments where the working set of entries is a few hundred thousand entries, the entry cache doubles the throughput of operations for up to 1000 concurrent clients.

For directory deployments with a larger working set of directory entries and a higher concurrency of clients, using the multiprocess directory server instance and the Oracle buffer cache results in greater scalability.


See Also:

"Setting System Operational Attributes" for information about attributes you set to enable and configure entry caching

25.8 Caching of Connection DNs

Each time the server performs a bind operation, it computes the list of privileged groups, including nested groups, that the identity (connection DN) performing the bind is a member of. The computed list of privilege groups for each connection DN is cached in the Oracle Internet Directory server. The number of connection DNs whose privileged groups can be cached is controlled by the attribute orclmaxconnincache in the DSA configuration entry. The default value is 25000 identities (connection DNs). Increase the value of orclmaxconnincache if your installation has more than 25000 users. For example, to increase orclmaxconnincache to 50000 users, you would create an LDIF file similar to this:

dn: cn=dsaconfig,cn=configsets,cn=oracle internet directory
changetype:modify
replace: orclmaxconnincache
orclmaxconnincache: 50000 

and then use a command line similar to this:

ldapmodify -p port -D cn=orcladmin -w adminPasswd -f filename

25.9 Optimizing Searches

This section contains these topics:

25.9.1 Optimizing Subtree Searches

When searching a subtree, the server does not write to the client until a configured number of entries have been processed. This number is controlled by the attribute orclmaxentinber in the DSA configuration entry. By default this value is 5. If the entries are larger than 8000 bytes, reduce this value to 1.

25.9.2 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 the latency unacceptably high, there are steps you can take to reduce it.

The simplest step is to reduce the number of attributes you are searching for. 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.

If you still see unacceptable latency, even with required attributes specified, then there are two tuning techniques you can try for reducing latency. These are known as the "Entry Cache Enabled Configuration" and "Entry Cache Disabled Configuration" respectively.

25.9.2.1 Entry Cache Enabled Configuration

In this technique, you try to cache the large group entry in the entry cache. To do this, increase the value of the orclEcacheMaxEntSize attribute in the Oracle Internet Directory server configuration entry (cn=dsaconfig,cn=configsets,cn=oracle internet directory). This attribute controls the maximum size of a cache entry. The default value is 1M. If the size of the large group entry is greater than the value of orclEcacheMaxEntSize, change it to a large enough value to ensure that the large group entry is cached.


Note:

  • If you expect frequent updates to large groups, then do not use this tuning methodology. Use "Entry Cache Disabled Configuration" instead.

  • If you are using a multiserver LDAP instance or if this server is part of a high availability configuration with Oracle Internet Directory servers on different machines connecting to the same database, then the entry cache is automatically disabled Use "Entry Cache Disabled Configuration" instead.


25.9.2.2 Entry Cache Disabled Configuration

In this technique, you disable the entry cache by setting the value of the attribute orclecacheenabled to 0 (zero) in the root DSE entry. The steps are as follows:

  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.


Note:

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%.

25.9.3 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.

25.9.3.1 Optimizing Searches for Skewed Attributes by Using Oracle Directory Manager

To optimize queries to the database:

  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. The fields in the Query Optimization tab page are listed and described in Table A-44.

  3. In the Query Optimization tab page, in the Attributes with Low Cardinality field, enter the attributes you want to designate as skewed.

  4. Choose Apply.

25.9.3.2 Optimizing Searches for Skewed Attributes by Using ldapmodify

To optimize the search for a skewed attribute, you use ldapmodify to add it as a value of the orclskewedattribute attribute.

For example, to add my_attribute to the orclskewedattribute attribute, you would enter the following:

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
!

25.10 Setting the Time Limit Mode

When you set the server operation time limit as described in "Setting System Operational Attributes", you specified the maximum number of seconds allowed for a search to be completed. To adjust server performance, you can also set the search time limit mode to be either accurate or approximate. If you specify it as accurate, then searches end precisely at the specified number of seconds. If you specify it as approximate, then searches end within a few seconds of the specified number of seconds. In smaller workloads, the latter provides better performance.

25.10.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.

25.10.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.

25.11 Setting the Timeout for Client/Server Connections

You can specify the amount of idle time allowed for connections between clients and the directory server. To set the timeout for client/server connections:

  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 LDAP Connection Timeout field, enter the maximum number of seconds that the directory client can remain idle before the connection is terminated. The default is 0, meaning that there is no timeout.

  4. Choose Apply.

25.12 Setting the Timeout for Write Operations

When an LDAP client initiates an operation, then does not respond to the server for a configured number of seconds, the server closes the connection. The number of seconds is controled by the attribute orclnwrwtimeout in the DSA configuration entry. The default is 300 seconds. To increase it to 500 seconds, you would create an LDIF file similar to this:

dn: cn=dsaconfig,cn=configsets,cn=oracle internet directory
changetype:modify
replace: orclnwrwtimeout
orclnwrwtimeout: 500 

and then use a command line similar to this:

ldapmodify -p port -D cn=orcladmin -w adminPasswd -f filename