Skip Navigation Links | |
Exit Print View | |
Oracle Directory Server Enterprise Edition Deployment Planning Guide 11g Release 1 (11.1.1.5.0) |
Part I Overview of Deployment Planning for Directory Server Enterprise Edition
1. Introduction to Deployment Planning for Directory Server Enterprise Edition
2. Business Analysis for Directory Server Enterprise Edition
Part II Technical Requirements
3. Usage Analysis for Directory Server Enterprise Edition
4. Defining Data Characteristics
5. Defining Service Level Agreements
6. Tuning System Characteristics and Hardware Sizing
Directory Server and Directory Proxy Server LDAP and LDAPS Port Numbers
Directory Server DSML Port Numbers
Directory Service Control Center and Common Agent Container Port Numbers
Identity Synchronization for Windows Port Numbers
Hardware Sizing For Directory Service Control Center
Hardware Sizing For Directory Proxy Server
Configuring Worker Threads and Backend Connections
Disk Space for Directory Proxy Server
Network Connections for Directory Proxy Server
Hardware Sizing For Directory Server
Directory Server Database Page Size
Directory Server Administration Files
Directory Server Threads and File Descriptors
Simulating Client Application Load
Directory Server and Processors
Directory Server and Local Disk Space
Directory Server and Network Connectivity
Limiting Directory Server Resources Available to Clients
Limiting System Resources Used By Directory Server
Operating System Tuning For Directory Server
Operating System Version and Patch Support
System-Specific Tuning With The idsktune Command
Transmission Control Protocol (TCP) Settings
Physical Capabilities of Directory Server
Other Tips to Improve Overall Performance
For Maximum Search Rate (Searches Only)
For Maximum Modification Rate (Modifications Only)
Small, Medium, and Large Data Sets
Tuning Indexes for Performance
Basic Directory Server Sizing Example: Disk and Memory Requirements
Preparing a Directory Server Instance
Populating the Suffix With 10,000 Sample Directory Entries
Populating the Suffix With 100,000 Sample Directory Entries
Populating the Suffix With 1,000,000 Sample Directory Entries
7. Identifying Security Requirements
8. Identifying Administration and Monitoring Requirements
9. Designing a Basic Deployment
10. Designing a Scaled Deployment
11. Designing a Global Deployment
12. Designing a Highly Available Deployment
Part IV Advanced Deployment Topics
13. Using LDAP-Based Naming With Solaris
14. Deploying a Virtual Directory
This section provides recommendations for setting database and entry cache sizes. It does not cover import cache sizes. The recommendations here pertain to maximizing either search rate or modify rate, not both at once.
This section covers the following topics:
Here you find the basic recommendations for maximizing search rates or maximizing modification rates achieved by Directory Server. Set cache sizes according to the following recommendations:
If the directory data do not fit into available physical memory, or only just fit with no extra room to spare, set cache sizes to their default values, 32M for db-cache-size, 10M for entry-cache-size, and allow the server to use as much of the operating system's file system cache as possible. Run tests to correctly dimension the sizes based on your throughput.
If the directory data fit into available physical memory with physical memory to spare, allocate memory to the entry cache until either the entry cache is full or, on a 32–bit system, the entry cache reaches maximum size. Then allocate memory to the database cache until it is full or reaches maximum size.
See Configuring Memory in Oracle Directory Server Enterprise Edition Administration Guide for instructions on setting cache sizes.
If the directory data do not fit into available physical memory, or only just fit with no extra room to spare, set the entry cache sizes to the default value, 10M for entry-cache-size and allow the server to use as much of the operating system's file system cache as possible. Keeping some database cache available ensures that modifications remain cached between each database checkpoint.
If the directory data fit into available physical memory with physical memory to spare, allocate memory to the entry cache until either the entry cache is full or, on a 32–bit system, the entry cache reaches maximum size. Then allocate memory to the database cache until it is full or reaches maximum size.
See Configuring Memory in Oracle Directory Server Enterprise Edition Administration Guide for instructions on setting cache sizes.
A working set refers to the data actually pulled into memory so that the server can respond to client applications. The data set is then the entries in the directory that are being used due to client traffic. The data set may include every entry in the directory, or may be composed of some smaller number of entries, such as entries corresponding to people in a time zone where users are active.
We define three data set sizes, based on how much of the directory data set fits into available physical memory:
The data set fits entirely into physical memory with fully-loaded database and entry caches.
The data set fits in physical memory, and extra physical memory can be dedicated to entry cache.
The data set is too small to fit completely in available physical memory.
The ideal case is of course the small data set. If your data set is small, set database cache size and entry cache size such that all entries fit in both the database cache and the entry cache.
The following sections provide recommendations for medium and large data sets where the server performs either all searches or all modify operations.
Figure 6-1 shows search performance on a hypothetical system. As expected, Directory Server offers top search performance for a given system configuration when the whole data set fits into memory.
Figure 6-1 Search Performance
For large data sets better performance has been observed when database cache and entry cache are set to their minimum sizes and available memory is left to the operating system for use in allocating file system cache. As shown, performance improves when more of the data set fits into the file system cache.
For medium data sets better performance has been observed when the file system cache holds the whole data set, and extra physical memory available is devoted to entry cache. As shown, performance improves when more of the medium data set fits in entry cache.
Figure 6-2 shows modify performance on a hypothetical system. As expected, Directory Server offers top modify performance for a given system configuration when the whole data set fits into memory.
Figure 6-2 Modify Performance
For large data sets better performance has been observed when database cache and entry cache are set to their minimum sizes and available memory is left to the operating system for use in allocating file system cache. As shown, performance improves when more of the data set fits into the file system cache.
For medium data sets, modify performance reaches its maximum as all entries fit into file system cache. As suggested in Basic Tuning Recommendations, keeping some database cache available ensures the modifications to remain cached between each database checkpoint.