A Directory Server Enterprise Edition deployment requires that certain system characteristics be defined at the outset. This chapter describes the system information that you need to address in the planning phase of your deployment.
This chapter covers the following topics:
When identifying the host systems that will be used in your deployment, consider the following:
Will the system be dedicated to a single server?
Will the system be running other applications, and if so, what will the other applications be?
What percentage of the system's resources will these applications require?
When the host systems have been identified, select a host name for each host in the topology. Make sure that each host system has a static IP address.
Restrict physical access to the host system. Although Directory Server Enterprise Edition includes many security features, directory security is compromised if physical access to the host system is not controlled.
If the Directory Server instances do not provide a naming service for the network, or if the deployment involves remote administration, a naming service and the domain name for the host must be properly configured.
At design time, select port numbers for each Directory Server and Directory Proxy Server instance. If possible, do not change port numbers after your directory service is deployed in a production environment.
Separate port numbers must be allocated for various services and components.
Directory Server and Directory Proxy Server LDAP and LDAPS Port Numbers
Directory Service Control Center and Common Agent Container Port Numbers
Specify the port number for accepting LDAP connections. The standard port for LDAP communication is 389, although other ports can be used. For example, if you must be able to start the server as a regular user, use an unprivileged port, by default 1389. Port numbers less than 1024 require privileged access. If you use a port number that is less than 1024, certain LDAP commands must be run as root.
Specify the port number for accepting SSL-based connections. The standard port for SSL-based LDAP (LDAPS) communication is 636, although other ports can be used, such as the default 1636 when running as a regular user. For example, an unprivileged port might be required so that the server can be started as a regular user.
If you specify a non-privileged port and a server instance is installed on a system to which other users have access, you might expose the port to a hijack risk by another application. In other words, another application can bind to the same address/port pair. The rogue application might then be able to process requests that are intended for the server. The application could also be used to capture passwords used in the authentication process, to alter client requests or server responses, or to produce a denial of service attack.
Both Directory Server and Directory Proxy Server allow you to restrict the list of IP addresses on which the server listens. Directory Server has configuration attributes nsslapd-listenhost and nsslapd-securelistenhost. Directory Proxy Server has listen-address properties on ldap-listener and ldaps-listener configuration objects. When you specify the list of interfaces on which to listen, other programs are prevented from using the same port numbers as your server.
In addition to processing requests in LDAP, Directory Server also responds to requests sent in the Directory Service Markup Language v2 (DSML). DSML is another way for a client to encode directory operations. Directory Server processes DSML as any other request, with the same access control and security features.
If your topology includes DSML access, identify the following:
A standard HTTP port for receiving DSML requests. The default port is 80.
If SSL is activated, an encrypted (HTTPS) port for receiving encrypted DSML requests. The default port is 443.
A relative URL that, when appended to the host and port, determines the complete URL that clients must use to send DSML requests
For information about configuring DSML, see To Enable the DSML-over-HTTP Service in Sun Java System Directory Server Enterprise Edition 6.2 Administration Guide.
Directory Service Control Center, DSCC, is a web application for Sun Java Web Console that enables you to administer Directory Server and Directory Proxy Server instances through a web browser. For a server to be recognized by DSCC, the server must be registered with DSCC. Unregistered servers can still be managed using command-line utilities.
DSCC communicates with DSCC agents located on the systems where servers are installed. The DSCC agents run inside a common agent container, which routes network traffic to them and provides them a framework in which to run.
If you plan to use DSCC to administer servers in your topology, identify the following port numbers.
The encrypted HTTPS port for accessing DSCC through Sun Java Web Console on the system where DSCC is installed. The default port is 6789.
The management traffic port for DSCC to access its agents local to the server through the common agent container, default: 11162, on the system where the server instances are installed.
The port numbers for the DSCC Registry instance, if you plan to replicate the configuration information. See dsccsetup(1M) for details.
Even if all components are installed on the same system, DSCC still communicates with its agents through these network ports.
If your deployment includes identity synchronization with Microsoft Active Directory, an available port is required for the Message Queue instance. This port must be available on each Directory Server instance that participates in the synchronization. The default non-secure port for Message Queue is 80, and the default secure port is 443.
You must also make additional installation decisions and configuration decisions when planning your deployment. For details on installing and configuring Identity Synchronization for Windows, see Part II, Installing Identity Synchronization for Windows, in Sun Java System Directory Server Enterprise Edition 6.2 Installation Guide.
DSCC runs as a web application inside Sun Java Web Console, which runs inside a web application container. DSCC also runs its own local instance of Directory Server to store configuration data.
The minimum requirement to run DSCC is 256 megabytes of memory and 100 megabytes of free disk space. However, for optimum performance run DSCC on a system with at least one gigabyte of memory devoted to DSCC and a couple gigabytes of free disk space.
Directory Proxy Server runs as a multithreaded Java program, and is built to scale across multiple processors. In general, the more processing power available the better, though you might find that in practice adding memory, faster disks, or faster network connections can enhance performance more than additional processors.
Directory Proxy Server uses memory mainly to hold information that is being processed. Complex aggregations for processing some virtual directory requests against multiple data sources may temporarily use extra memory. If one of your data sources is an LDIF file, Directory Proxy Server constructs a representation of that data source in memory. However, unless you use large LDIF data sources, not a recommended deployment practice, a couple gigabytes of memory devoted to Directory Proxy Server should suffice. You might want to increase the Java virtual machine heap size when starting Directory Proxy Server if enough memory is available. For example, to set the Java virtual machine heap size to 1000 megabytes, use the following command.
$ dpadm set-flags instance-path jvm-args="-Xmx1000M -Xms1000M -XX:NewRatio=1" |
This command uses the -XX:NewRatio option, which is specific to the Sun Java virtual machine. The default heap size is 250 megabytes.
Directory Proxy Server allows you to configure how many threads the server maintains to process requests. You configure this using the server property number-of-worker-threads, described in number-of-worker-threads(5dpconf). As a rule of thumb, try setting this number to 50 threads plus 20 threads for each data source used. To gauge whether the number is sufficient, monitor the status of the Directory Proxy Server work queue on cn=Work Queue,cn=System Resource,cn=instance-path,cn=Application System,cn=DPS6.0,cn=Installed Product,cn=monitor. If you find that the operationalStatus for the work queue is STRESSED, this can mean thread-starved connection handlers are unable to handle new client requests. Increasing number-of-worker-threads may help if more system resources are available for Directory Proxy Server.
The number of worker threads should also be appropriate for the number of backend connections. If there are too many worker threads for the number of backend connections, incoming connections are accepted but cannot be transmitted to the backend connections. Such a situation is generally problematic for client applications.
To determine whether this situation has arisen, check the log files for error messages of the following type: "Unable to get backend connections". Alternatively, look at the cn=monitor entry for load balancing. If the totalBindConnectionsRefused attribute in that entry is not null, the proxy was unable to process certain operations because there were not enough backend connections. To solve this issue, increase the maximum number of backend connections. You can configure the number of backend connections for each data source by using the num-bind-limit, num-read-limit and num-write-limit properties of the data source. If you have already reached the limit for backend connections, reduce the number of worker threads.
If there are not enough worker threads for the number of backend connections, so much work can pile up in the server's queue that no new connections can be handled. Client connections can then be refused at the TCP/IP level, with no LDAP error returned. To determine if this situation has arisen, look at the statistics in the cn=monitor entry for the work queue. In particular, readConnectionsRefused and writeConnectionsRefused should remain low. Also, the value of the maxNormalPriorityPeak attribute should remain low.
By default Directory Proxy Server requires up to one gigabyte of local disk space for access logging, and another gigabyte of local disk space for errors logging. Given the quantity of access log messages Directory Proxy Server writes when handling client application requests, logging can be a performance bottleneck. Typically, however, you must leave logging on in a production environment. For best performance therefore put Directory Proxy Server logs on a fast, dedicated disk subsystem. See Configuring Directory Proxy Server Logs in Sun Java System Directory Server Enterprise Edition 6.2 Administration Guide for instructions on adjusting log settings.
Directory Proxy Server is a network-intensive application. For each client application request, Directory Proxy Server may send multiple operations to different data sources. Make sure the network connections between Directory Proxy Server and your data sources are fast, with plenty of bandwidth and low latency. Also make sure the connections between Directory Proxy Server and client applications can handle the amount of traffic you expect.
Getting the right hardware for a medium to large Directory Server deployment involves some testing with data similar to the data you expect to serve in production, and access patterns similar to those you expect from client applications. When optimizing for particular systems, make sure you understand how system buses, peripheral buses, I/O devices, and supported file systems work. This knowledge helps you take advantage of I/O subsystem features when tuning these features to support Directory Server. Sun Services can help you make the right deployment decisions, including sizing the hardware to your requirements.
This section looks at how to approach hardware sizing for Directory Server. It covers what to consider when deciding how many processors, how much memory, how much disk space, and what type of network connections to dedicate to Directory Server in your deployment.
This section covers the following topics:
Unless indicated otherwise, the server properties described in the following sections can be set with the dsconf command. For more information about using dsconf, see dsconf(1M).
To tune performance implies modification of the default configuration to reflect specific deployment requirements. The following list of process phases covers the key things to think about when tuning Directory Server.
Define specific, measurable objectives for tuning, based on deployment requirements.
Consider the following questions.
Which applications use Directory Server?
Can you dedicate the entire system to Directory Server?
Does the system run other applications?
If so, which other applications run on the system?
How many entries are handled by the deployment?
How large are the entries?
How many searches per second must Directory Server support?
What types of searches are expected?
How many updates per second must Directory Server support?
What types of updates are expected?
What sort of peak update and search rates are expected?
What average rates are expected?
Does the deployment call for repeated bulk import initialization on this system?
If so, how often do you expect to import data? How many entries are imported?
What types of entries?
Must initialization be performed online with the server running?
The list here is not exhaustive. Ensure that your list of goals is exhaustive.
Determine how you plan to implement optimizations. Also, determine how you plan to measure and analyze optimizations.
Consider the following questions.
Can you change the hardware configuration of the system?
Are you limited to using hardware that you already have, tuning only the underlying operating system, and Directory Server?
How can you simulate other applications?
How should you generate representative data samples for testing?
How should you measure results?
How should you analyze results?
Carry out the tests that you planned. For large, complex deployments, this phase can take considerable time.
Check whether the potential optimizations tested reach the goals defined at the outset of the process.
If the optimizations reach the goals, document the results.
If the optimizations do not reach the goals, profile and monitor Directory Server.
Profile and monitor the behavior of Directory Server after applying the potential modifications.
Collect measurements of all relative behavior.
Plot and analyze the behavior that you observed while profiling and monitoring. Attempt to find evidence and to discover patterns that suggest further tests.
You might need to go back to the profiling and monitoring phase to collect more data.
Apply further potential optimizations suggested by your analysis of measurements.
Return to the phase of performing tests.
When the optimizations applied reach the goals defined at the outset of the process, document the optimizations well so the optimizations can be easily reproduced.
How much disk and memory space you devote to Directory Server depends on your directory data. If you already have representative data in LDIF, use that data when sizing hardware for your deployment. Representative data here means sample data that corresponds to the data you expect to use in deployment, but not actual data you use in deployment. Real data comes with real privacy concerns, can be multiple orders of magnitude larger than the specifications need to generate representative data, and may not help you exercise all the cases you want to test. Representative data includes entries whose average size is close to the size you expect to see in deployment, whose attributes have values similar to those you expect to see in deployment, and whose numbers are present in proportions similar to those you expect to see in deployment.
Take anticipated growth into account when you are deciding on representative data. It is advisable to include an overhead on current data for capacity planning.
If you do not have representative data readily available, you can use the makeldif(1) command to generate sample LDIF, which you can then import into Directory Server. Chapter 4, Defining Data Characteristics can help you figure out what representative data would be for your deployment. The makeldif command is one of the Directory Server Resource Kit tools.
For deployments expected to serve millions of entries in production, ideally you would load millions of entries for testing. Yet loading millions of entries may not be practical for a first estimate. Start by creating a few sets of representative data, for example 10,000 entries, 100,000 entries, and 1,000,000 entries, import those, and extrapolate from the results you observe to estimate the hardware required for further testing. When you are estimating hardware requirements, make provision for data that will be replicated to multiple servers.
Notice when you import directory data from LDIF into Directory Server the resulting database files (including indexes) are larger than the LDIF representation. The database files, by default, are located under the instance-path/db/ directory.
Directory Server default configuration settings are defined for typical small deployments and to make it easy to install and evaluate the product. This section examines some key configuration settings to adjust for medium to large deployments. In medium to large deployments you can often improve performance significantly by adapting configuration settings to your particular deployment.
When Directory Server reads or writes data, it works with fixed blocks of data, called pages. By increasing the page size you increase the size of the block that is read or written in one disk operation.
The page size is related to the size of entries and is a critical element of performance. If you know that the average size of your entries is greater than 4 kilobytes, you must increase the database page size. The database page size should also match the file system disk block size.
Directory Server is designed to respond quickly to client application requests. In order to avoid waiting for directory data to be read from disk, Directory Server caches data in memory. You can configure how much memory is devoted to cache for database files, for directory entries, and for importing directory data from LDIF.
Ideally the hardware on which you run Directory Server allows you to devote enough space to cache all directory data in physical memory. The data should fit comfortably, such that the system has enough physical memory for operation, and the file system has plenty of physical memory for its caching and operation. Once the data are cached, Directory Server has to read data from and write data to disk only when a directory entry changes.
Directory Server supports 64–bit memory addressing, and so can handle total cache sizes as large as a 64–bit processor can address. For small to medium deployments it is often possible to provide enough memory that all directory data can be held in cache. For large deployments, however, caching everything may not be practical or cost effective.
For large deployments, caching everything in memory can cause side effects. Tools such as the pmap command, that traverse the process memory map to gather data, can freeze the server process for a noticeable time. Core files can become so large that writing them to disk during a crash can take several minutes. Startup times can be slow if the server is shut down abruptly and then restarted. Directory Server can also pause and stop responding temporarily when it reaches a checkpoint and has to flush dirty cached pages to disk. When the cache is very large, the pauses can become so long that monitoring software assumes Directory Server is down.
I/O buffers at the operating system level can provide better performance. Very large buffers can compensate for smaller database caches.
For a detailed discussion of cache and cache settings, read Chapter 5, Directory Server Data Caching, in Sun Java System Directory Server Enterprise Edition 6.2 Reference.
Directory Server indexes directory entry attribute values to speed searches for those values. You can configure attributes to be indexed in various ways. For example, indexes can help Directory Server determine quickly whether an attribute has a value, whether it has a value equal to a given value, and whether it has a value containing a given substring.
Indexes can add to search performance, but they can also impact write performance. When an attribute is indexed, Directory Server has to update the index as values of the attribute change.
Directory Server saves index data to files. The more indexes you configure, the more disk space required. Directory Server indexes and data files are found, by default, under the instance-path/db/ directory.
For a detailed discussion of indexing and index settings, read Chapter 6, Directory Server Indexing, in Sun Java System Directory Server Enterprise Edition 6.2 Reference.
Some Directory Server administration files can potentially become very large. These files include the LDIF files containing directory data, backups, core files, and log files.
Depending on your deployment, you may use LDIF both to import Directory Server data, and to serve as auxiliary backup. A standard text format, LDIF allows you to export binary data as well as strings. LDIF can occupy significant disk space in large deployments. For example, a directory containing 10 million entries having an average size of 2 kilobytes, would in LDIF representation occupy 20 gigabytes on disk. You might maintain multiple LDIF files of that size if you use the format for auxiliary backup.
Binary backup files also occupy space on disk, at least until you move them somewhere else for safekeeping. Backup files produced with Directory Server utilities consist of binary copies of the directory database files. Alternatively for large deployments you can put Directory Server in frozen mode and take a snapshot of the file system. Either way, you must have disk space available for the backup.
By default Directory Server writes log messages to instance-path/logs/access and instance-path/logs/errors. By default Directory Server requires one gigabyte of local disk space for access logging, and another 200 megabytes of local disk space for errors logging.
For a detailed discussion of Directory Server logging, read Chapter 7, Directory Server Logging, in Sun Java System Directory Server Enterprise Edition 6.2 Reference.
Directory Server lets you replicate directory data for availability and load balancing between the servers in your deployment. Directory Server allows you to have multiple read-write (master) replicas deployed together.
Internally, the server makes this possible by keeping track of changes to directory data. When the same data are modified on more than one read-write replica Directory Server can resolve the changes correctly on all replicas. The data to track these changes, must be retained until they are no longer needed for replication. By default changes are retained for seven days. If your directory data undergoes much modification, especially of large multi-valued attributes, this data can grow quite large.
For a detailed discussion of Directory Server replication, read Chapter 4, Directory Server Replication, in Sun Java System Directory Server Enterprise Edition 6.2 Reference.
Directory Server runs as a multithreaded process, and is designed to scale on multiprocessor systems. You can configure the number of threads Directory Server creates at startup to process operations. By default Directory Server creates 30 threads. The value is set using the dsconf(1M) command to adjust the server property thread-count.
The trick is to keep the threads as busy as possible without incurring undo overhead from having to handle many threads. As long as all directory data fits in cache, better performance is often seen when thread-count is set to twice the number of processors plus the expected number of simultaneous update operations. If only a fraction of a large directory data set fits in cache, Directory Server threads may often have to wait for data being read from disk. In that case you may find performance improves with a much higher thread count, up to 16 times the number of available processors.
Directory Server uses file descriptors to hold data related to open client application connections. By default Directory Server uses a maximum of 1024 file descriptors. The value is set using the dsconf command to adjust the server property file-descriptor-count. If you see a message in the errors log stating too many fds open, you may observe better performance by increasing file-descriptor-count, presuming your system allows Directory Server to open additional file descriptors.
The file-descriptor-count property does not apply on Windows.
Once in deployment Directory Server use is likely to grow. Planning for growth is key for a successful deployment, in which you continue to provide a consistently high level of service. Plan for larger, more powerful systems than you need today, basing your requirements in part on the growth you expect tomorrow.
Sometimes directory services must grow rapidly, even suddenly. This is the case for example when a directory service sized for one organization is merged with that of another organization. By preparing for growth in advance and by explicitly identifying your expectations, you are better equipped to deal with rapid and sudden growth, because you know in advance whether the expected increase outstrips the capacity you planned.
Basic recommendations follow. These recommendations apply in most situations. Although the recommendations presented here are in general valid, avoid the temptation to apply the recommendations without understanding the impact on the deployment at hand. This section is intended as a checklist, not a cheat sheet.
Adjust cache sizes.
Ideally, the server has enough available physical memory to hold all caches used by Directory Server. Furthermore, an appropriate amount of extra physical memory is available to account for future growth. When plenty of physical memory is available, set the entry cache size large enough to hold all entries in the directory. Use the entry-cache-size suffix property. Set the database cache size large enough to hold all indexes with the db-cache-size property. Use the dn-cache-size or dn-cache-count properties to control the size of the DN cache.
Optimize indexing.
Remove unnecessary indexes. Add additional indexes to support expected requests.
From time to time, you can add additional indexes that support requests from new applications. You can add, remove, or modify indexes while Directory Server is running. Use for example the dsconf create-index and dsconf delete-index commands.
Be careful not to remove system indexes. For a list of system indexes, see System Indexes and Default Indexes in Sun Java System Directory Server Enterprise Edition 6.2 Reference.
Directory Server gradually indexes data after you make changes to the indexes. You can also force Directory Server to rebuild indexes with the dsconf reindex command.
Allow only indexed searches.
Unindexed searches can have a strong negative impact on server performance. Unindexed searches can also consume significant server resources.
Consider forcing the server to reject unindexed searches by setting the require-index-enabled suffix property to on.
Adjust the maximum number of values per index key with the all-ids-threshold property.
Tune the underlying operating system according to recommendations made by the idsktune command. For more information, see idsktune(1M).
Adjust operational limits.
Adjustable operational limits prevent Directory Server from devoting inordinate resources to any single operation. Consider assigning unique bind DNs to client applications requiring increased capabilities, then setting resource limits specifically for these unique bind DNs.
Distribute disk activity.
Especially for deployments that support large numbers of updates, Directory Server can be extremely disk I/O intensive. If possible, consider spreading the load across multiple disks with separate controllers.
Disable unnecessary logging.
Disk access is slower than memory access. Heavy logging can therefore have a negative impact on performance. Reduce disk load by leaving audit logging off when not required, such as on a read-only server instance. Leave error logging at a minimal level when not using the error log to troubleshoot problems. You can also reduce the impact of logging by putting log files on a dedicated disk, or on a lesser used disk, such as the disk used for the replication changelog.
When replicating large numbers of updates, consider adjusting the appropriate replication agreement properties.
The properties are transport-compression, transport-group-size, and transport-window-size.
On Solaris systems, move the database home directory to a tmpfs file system.
The database home directory, specified by the db-env-path property, indicates where Directory Server locates database cache backing files. Data files continue to reside by default under instance-path/db.
With the database cache backing files on a tmpfs file system, the system does not repeatedly flush the database cache backing files to disk. You therefore avoid a performance bottleneck for updates. In some cases, you also avoid the performance bottleneck for searches. The database cache memory is mapped to the Directory Server process space. The system essentially shares cache memory and memory used to hold the backing files in the tmpfs file system. You therefore gain performance at essentially no cost in terms of memory space needed.
The primary cost associated with this optimization is that database cache must be rebuilt after a restart of the host machine. This cost is probably not a cost that you can avoid, however, if you expect a restart to happen only after a software or hardware failure. After such a failure, the database cache must be rebuilt anyway.
Enable transaction batches if you can afford to lose updates during a software or hardware failure.
You enable transaction batches by setting the server property db-batched-transaction-count.
Each update to the transaction log is followed by a sync operation to ensure that update data is not lost. By enabling transaction batches, updates are grouped together before being written to the transaction log. Sync operations only take place when the whole batch is written to the transaction log. Transaction batches can therefore significantly increase update performance. The improvement comes with a trade off. The trade off is during a crash, you lose update data not yet written to the transaction log.
With transaction batches enabled, you lose up to db-batched-transaction-count - 1 updates during a software or hardware failure. The loss happens because Directory Server waits for the batch to fill, or for 1 second, whichever is sooner, before flushing content to the transaction log and thus to disk.
Do not use this optimization if you cannot afford to lose updates.
Configure the referential integrity plug-in to delay integrity checks.
The referential integrity plug-in ensures that when entries are modified, or deleted from the directory, all references to those entries are updated. By default, the processing is performed synchronously, before the response for the delete operation is returned to the client. You can configure the plug-in to have the updates performed asynchronously. Use the ref-integrity-check-delay server property.
To measure Directory Server performance, you prepare the server, then subject it to the kind of client application traffic you expect in production. The better you reproduce the kind of access patterns client applications that happen in production, the better job you can do sizing the hardware and configuring Directory Server appropriately.
Directory Server Resource Kit provides the authrate(1), modrate(1), and searchrate(1) commands you can use for basic tests. These commands let you measure the rate of binds, modifications, and searches your directory service can support.
You can also simulate, measure, and graph complex, realistic client access using SLAMD. The SLAMD Distributed Load Generation Engine (SLAMD) is a Java application that is designed to stress test and analyze the performance of network-based applications. It was originally developed by Sun Microsystems, Inc. to benchmark and analyze the performance of LDAP Directory Servers. SLAMD is available as an open source application under the Sun Public License, an OSI-approved open source license. To obtain information about SLAMD, go to http://www.slamd.com/. SLAMD is also available as a java.net project. See https://slamd.dev.java.net/.
As a multithreaded process built to work on systems with multiple processors, Directory Server performance scales linearly in most cases as you devote more processors to it. When running Directory Server on a system with many processors, consider using the dsconf command to adjust the server property thread-count, which is the number of threads Directory Server starts to process server operations.
In specific directory deployments, however, adding more processors might not significantly impact performance. When handling demanding performance requirements for searching, indexing, and replication, consider load balancing and directory proxy technologies as part of the solution.
The following factors significantly affect the amount of memory needed:
Directory Server database cache, entry cache, and import cache settings
Peak replication load
Peak client application load
Server settings for file-descriptor-count and thread-count
Overhead for the operating system, other applications running on the system, and system administration activity
To estimate the memory size required to run Directory Server, estimate the memory needed for a specific Directory Server configuration on a system loaded as in production, including application load generated for example using the Directory Server Resource Kit commands or SLAMD.
Before you measure Directory Server process size, give the server some time after startup to fill entry caches as during normal or peak operation. If you have space to put everything in cache memory, you can speed this warm up period for Directory Server by reading every entry in the directory to fill entry caches. If you do not have space to put everything in cache memory, simulate client access for some time until the cache fills as it would with a pattern of normal or peak operation.
With the server in an equilibrium state, you can use utilities such as pmap on Solaris or Linux, or the Windows Task Manager to measure memory used by the Directory Server process, ns-slapd on UNIX systems, slapd.exe on Windows systems. For more information, see the pmap(1) man page. Measure process size both during normal operation and peak operation before deciding how much memory to use.
Make sure to add to your estimates the amount of memory needed for system administration, and for the system itself. Operating system memory requirements can vary widely depending on the system configuration. Therefore, estimating the memory needed to run the underlying operating system must be done empirically. After tuning the system, monitor memory use to your estimate. You can use utilities such as the Solaris vmstat and sar commands, or the Task Manager on Windows to measure memory use.
At a minimum, provide enough memory so that running Directory Server does not cause constant page swapping, which negatively affects performance. Utilities such as MemTool, unsupported and available separately for Solaris systems, can be useful in monitoring how memory is used by and allocated to running applications.
If the system cannot accommodate additional memory, yet you continue to observe constant page swapping, reduce the size of the database and entry caches. Although you can throttle memory use with the heap-high-threshold-size and heap-low-threshold-size server settings, consider the heap threshold mechanism as a last resort. Performance suffers when Directory Server must delay other operations to free heap memory.
On Red Hat Linux systems, you can adjust the /proc/sys/vm/swappiness parameter to tune how aggressively the kernel swaps out memory. High swappiness means that the kernel will swap out a large amount and low swappiness means that the kernel will try not to use swap space at all. Decreasing the swappiness setting may therefore result in improved Directory performance as the kernel holds more of the server process in memory longer before swapping it out. If the system is dedicated to a single Directory Server instance, set the swappiness to zero. If the system runs several heavy processes or multiple concurrent instances of Directory Server, consider testing the Directory performance with various swappiness settings.
Disk use and I/O capabilities can have great impact on performance. The disk subsystem can become an I/O bottleneck, especially for a deployment that supports large numbers of modifications. This section recommends ways to estimate overall disk capacity for a Directory Server instance.
Do not install Directory Server or any data it accesses on network disks.
Directory Server software does not support the use of network-attached storage through NFS, AFS, or SMB. All configuration, database, and index files must reside on local storage at all times, even after installation. Log files can be stored on network disks.
The following factors significantly affect the amount of local disk space needed:
Number of directory entries
Average sizes of entries
Server database page size setting when directory data is imported
To adjust the database page size, set the nsslapd-db-page-size attribute. For more information, see Directory Server Database Page Size.
Number of indexes maintained on directory data
Size of stored LDIF, backups, logs, and core files
When you have set up indexes, adjusted the database page size, and imported directory data, you can estimate the disk capacity required for the instance by reading the size of the instance-path/ contents, and adding the size of expected LDIF, backups, logs, and core files. Also estimate how much the sizes you measure are expected to grow, particularly during peak operation. Make sure you leave a couple of gigabytes of extra space for the errors log in case you need to increase the log level and size for debugging purposes.
Getting an estimation of the disk required for directory data can be done in some cases by extrapolation. If it is not practical to load Directory Server with as much data as you expect in production, extrapolate from smaller sets of sample data as suggested in Making Sample Directory Data. When the amount of directory data you use is smaller than in production, you must extrapolate for other measurements, too.
The following factors determine how fast the local disk must be:
Level of updates sustained, including the volume of replication traffic
Whether directory data are mainly in cache or on disk
Log levels used for access and error logging, and whether the audit log is enabled
Whether directory data, logs, and the transaction log (for updates) can be placed on separate disk subsystems
Whether backups are performed with Directory Server online or offline
Disks used should not be saturated under normal operating circumstances. You can use tools such as the Solaris iostat command to isolate potential I/O bottlenecks.
To increase disk throughput distribute files across disk subsystems. Consider providing dedicated disk subsystems for transaction logs (dsconf set-server-prop db-log-path:/transaction/log/path), databases (dsconf create-suffix --db-path /suffix/database/path suffix-name), and log files (dsconf set-log-prop path:/log/file/path). In addition consider putting database cache files on a memory-based file system such as a Solaris tmpfs file system, where files are swapped to disk only if available memory is exhausted (for example, dsconf set-server-prop db-env-path:/tmp). If you put database cache files on a memory-based file system, make sure the system does not run out of space to keep that entire file system in memory.
To further increase throughput use multiple disks in RAID configuration. Large, non volatile I/O buffers and high-performance disk subsystems such as those offered in Sun StorEdgeTM products can greatly enhance Directory Server performance and uptime. On Solaris 10 systems, using ZFS can also improve performance.
Directory Server is a network-intensive application. You can estimate theoretical maximum throughput using the following formula. Notice that this formula does not account for replication traffic.
max. throughput = max. entries returned/second x average entry size
Imagine that a Directory Server must respond to a peak of 5000 searches per second and that the server returns one entry per search. The entries have an average size of 2000 bytes. The theoretical maximum throughput would be 10 megabytes, or 80 megabits, not counting replication. 80 megabits are likely to be more than a single 100-megabit Ethernet adapter can provide. To improve network availability for a Directory Server instance, equip the system with a faster connection, or with multiple network interfaces. Directory Server can listen on multiple network interfaces within the same process.
The preceding example assumes that the client application requests all attributes when reading or searching the directory. Generally, you should design client applications so that they request only the required attributes.
If you intend to cluster Directory Servers on the same network for load balancing purposes, make sure the network infrastructure can support the additional load generated for replication. If you plan multi-master replication over a wide area network, test your configuration to make sure the connection provides sufficient throughput with minimum latency and near-zero packet loss. High latency and packet loss both slow replication. In addition, avoid a topology where replication traffic goes through a load balancer.
The default configuration of Directory Server can allow client applications to use more Directory Server resources than are required.
The following uses of resources can hurt directory performance:
Opening many connections then leaving them idle or unused
Launching costly and unnecessary unindexed searches
Storing enormous and unplanned for binary attribute values
In some deployment situations, you should not modify the default configuration. For deployments where you cannot tune Directory Server, use Directory Proxy Server to limit resources, and to protect against denial of service attacks.
In some deployment situations, one instance of Directory Server must support client applications, such as messaging servers, and directory clients such as user mail applications. In such situations, consider using bind DN based resource limits to raise individual limits for directory intensive applications. The limits for an individual account can be adjusted by setting the attributes nsSizeLimit, nsTimeLimit, nsLookThroughLimit, and nsIdleTimeout on the individual entry. For information about how to control resource limits for individual accounts, see Setting Resource Limits For Each Client Account in Sun Java System Directory Server Enterprise Edition 6.2 Administration Guide.
Table 6–1 describes the parameters that set the global values for resource limits. The limits in Table 6–1 do not apply to the Directory Manager user, therefore, ensure client applications do not connect as the Directory Manager user.
Table 6–1 Tuning Recommendations For Resources Devoted to Client Applications
Tuning Parameter |
Description |
---|---|
Server property idle-timeout |
Sets the time in seconds after which Directory Server closes an idle client connection. Here idle means that the connection remains open, yet no operations are requested. By default, no time limit is set. You set this server property with the dsconf set-server-prop command. Some applications, such as messaging servers, may open a pool of connections that remain idle when traffic is low, but that should not be closed. Ideally, you might dedicate a replica to support the application in this case. If that is not possible, consider bind DN based individual limits. In any case, set this value high enough not to close connections that other applications expect to remain open, but set it low enough that connections cannot be left idle abusively. Consider setting it to 7200 seconds, which is 2 hours, for example. |
Attribute nsslapd-ioblocktimeout on dn: cn=config |
Sets the time in milliseconds after which Directory Server closes a stalled client connection. Here stalled means that the server is blocked either sending output to the client or reading input from the client. You set this attribute with the ldapmodify command. For Directory Server instances particularly exposed to denial of service attacks, consider lowering this value from the default of 1,800,000 milliseconds, which is 30 minutes. |
Server property look-through-limit |
Sets the maximum number of candidate entries checked for matches during a search. You set this server property with the dsconf set-server-prop command. Some applications, such as messaging servers, may need to search the entire directory. Ideally, you might dedicate a replica to support the application in this case. If that is not possible, consider bind DN based, individual limits. In any case, consider lowering this value from the default of 5000 entries, but not below the threshold value of search-size-limit. |
Attribute nsslapd-maxbersize on dn: cn=config |
Sets the maximum size in bytes for an incoming ASN.1 message encoded according to Basic Encoding Rules, BER. Directory Server rejects requests to add entries larger than this limit. You set this attribute with the ldapmodify command. If you are confident you can accurately anticipate maximum entry size for your directory data, consider changing this value from the default of 2097152, which is 2 MB, to the size of the largest expected directory entry. The next largest size limit for an update is the size of the transaction log file, nsslapd-db-logfile-size, which by default is 10 MB. |
Server property max-threads-per-connection-count |
Sets the maximum number of threads per client connection. You set this server property with the dsconf set-server-prop command. Some applications, such as messaging servers, may open a pool of connections and may issue many requests on each connection. Ideally, you might dedicate a replica to support the application in this case. If that is not possible, consider bind DN based, individual limits. If you anticipate that some applications may perform many requests per connection, consider increasing this value from the default of 5, but do not increase it to more than 10. Typically do not specify more than 10 threads per connection. |
Server property search-size-limit |
Sets the maximum number of entries Directory Server returns in response to a search request. You set this server property with the dsconf set-server-prop command. Some applications, such as messaging servers, may need to search the entire directory. Ideally, you might dedicate a replica to support the application in this case. If that is not possible, consider bind DN based, individual limits. In any case, consider lowering this value from the default of 2000 entries. |
Server property search-time-limit |
Sets the maximum number of seconds Directory Server allows for handling a search request. You set this server property with the dsconf set-server-prop command. Some applications, such as messaging servers, may need to perform very large searches. Ideally, you might dedicate a replica to support the application in this case. If that is not possible, consider bind DN based, individual limits. In any case, set this value as low as you can and still meet deployment requirements. The default value of 3600 seconds, which is 1 hour, is larger than necessary for many deployments. Consider using 600 seconds, which is 10 minutes, as a starting point for optimization tests. |
Table 6–2 describes the parameters that can be used to tune how a Directory Server instance uses system and network resources.
Table 6–2 Tuning Recommendations For System Resources
This section provides an example that shows initial steps in sizing Directory Server disk and memory requirements for deployment. The system used for this example was selected by chance and because it had sufficient processing power and memory to complete the sizing tasks quickly. It does not necessarily represent a recommended system for production use. You can it however to gain insight into how much memory and disk space might be required for production systems.
The following system information was observed using the Solaris Management Console (smc).
2 AMD64 CPUs (2.2 gigahertz)
Solaris 10 Operating System
4 gigabytes physical memory
40 gigabytes swap
Physical memory in use before Directory Server installation: 700 megabytes
Physical memory free before Directory Server installation: 3400 megabytes
CPU usage: 1%
Local disk: one partition formatted UFS with logging
For this example, the system was dedicated to Directory Server. No other user was logged in, and only the default system processes were running.
After unpacking the zip distribution, install Directory Server software on local disk space.
$ ./dsee_deploy install -c DS -i /local |
For convenience set environment variables as shown.
$ export PATH=/local/ds6/bin:/local/dsrk6/bin:/local/dsee6/bin:${PATH} $ export DIRSERV_PORT=1389 $ export LDAP_ADMIN_PWF=~/.pwd |
After installing the software and setting environment variables, create a Directory Server instance using default ports for LDAP and LDAPS, respectively.
$ dsadm create -p 1389 -P 1636 /local/ds Choose the Directory Manager password: Confirm the Directory Manager password: $ du -hs /local/ds 610K /local/ds |
Until you create a suffix, the Directory Server instance uses less than one megabyte of disk space.
$ dsadm start /local/ds Server started: pid=8046 $ dsconf create-suffix dc=example,dc=com Certificate "CN=hostname, CN=1636, CN=Directory Server, O=Sun Microsystems" presented by the server is not trusted. Type "Y" to accept, "y" to accept just once, "n" to refuse, "d" for more details: Y $ du -hs /local/ds 53M /local/ds |
For this example, make no additional changes to the default Directory Server configuration except those shown explicitly.
Using the makeldif command with the example files provided as part of Directory Server Resource Kit, you can create sample LDIF files from one kilobyte to one megabyte in size. See To Install Directory Server Enterprise Edition From Zip Distribution in Sun Java System Directory Server Enterprise Edition 6.2 Installation Guide for an example showing how to use the makeldif command.
The entries in these files are smaller than you would expect in a real deployment.
$ du -h /var/tmp/* 57M /var/tmp/100k.ldif 5.7M /var/tmp/10k.ldif 573M /var/tmp/1M.ldif |
An example entry from these files is shown in the following LDIF.
dn: uid=Aartjan.Aalders,ou=People,dc=example,dc=com objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson givenName: Aartjan sn: Aalders cn: Aartjan Aalders initials: AA uid: Aartjan.Aalders mail: Aartjan.Aalders@example.com userPassword: trj49xeq telephoneNumber: 935-748-6699 homePhone: 347-586-0252 pager: 906-399-8417 mobile: 452-898-9034 employeeNumber: 1000004 street: 64197 Broadway Street l: Lawton st: IN postalCode: 57924 postalAddress: Aartjan Aalders$64197 Broadway Street$Lawton, IN 57924 description: This is the description for Aartjan Aalders.
Begin sizing by importing the content of 10k.ldif, which occupies 5.7 megabytes on disk.
$ dsadm stop /local/ds Server stopped $ dsadm import -i /local/ds /var/tmp/10k.ldif dc=example,dc=com … |
With default indexing the content of 10k.ldif increases the size of the instance files by 72 megabytes - 53 megabytes, or 19 megabytes.
$ du -hs /local/ds 72M /local/ds |
If you index five more attributes, size increases by about seven megabytes.
$ dsconf create-index dc=example,dc=com employeeNumber street st \ postalCode description $ dsconf reindex dc=example,dc=com … ## example: Finished indexing. Task completed (slapd exit code: 0). $ du -hs /local/ds 79M /local/ds |
Observing memory size with the default cache settings, and nothing loaded from the suffix into entry cache yet, the server process occupies approximately 170 megabytes of memory with a heap size of about 56 megabytes.
$ dsadm start /local/ds Server started: pid=8482 $ pmap -x 8482 … Address Kbytes RSS Anon Locked Mode Mapped File 0000000000437000 61348 55632 55380 - rw--- [ heap ] … ---------------- ---------- ---------- ---------- ---------- total Kb 178444 172604 76532 - |
As you then prime the cache and examine output from the pmap command again, the heap grows by about 10 megabytes, and so does the total size of the process.
$ ldapsearch -D cn=Directory\ Manager -w - -p 1389 -b dc=example,dc=com \ objectclass=\* > /dev/null Enter bind password: $ pmap -x 8482 … Address Kbytes RSS Anon Locked Mode Mapped File … 0000000000437000 70564 65268 65024 - rw--- [ heap ] … ---------------- ---------- ---------- ---------- ---------- total Kb 187692 182272 86224 - |
The numbers are comparable for default indexing.
$ dsconf delete-index dc=example,dc=com employeeNumber street st \ postalCode description $ dsconf reindex dc=example,dc=com … ## example: Finished indexing. Task completed (slapd exit code: 0). $ dsadm stop /local/ds Server stopped $ dsadm start /local/ds Server started: pid=8541 $ ldapsearch -D cn=Directory\ Manager -w - -p 1389 -b dc=example,dc=com \ objectclass=\* > /dev/null Enter bind password: $ pmap -x 8541 … Address Kbytes RSS Anon Locked Mode Mapped File … 0000000000437000 70564 65248 65004 - rw--- [ heap ] … ---------------- ---------- ---------- ---------- ---------- total Kb 187680 182240 86192 - |
For only 10,000 entries, do not change the default cache sizes.
$ dsconf get-server-prop | grep cache db-cache-size : 32M import-cache-size : 64M $ dsconf get-suffix-prop dc=example,dc=com | grep entry-cache-size entry-cache-size : 10M |
The small default entry cache was no doubt filled completely after priming, even with only 10,000 entries. To see the size for a full entry cache, set a large entry cache size, import the data again, and prime the cache.
$ dsconf set-suffix-prop dc=example,dc=com entry-cache-size:2G $ dsadm stop /local/ds Server stopped $ dsadm import -i /local/ds /var/tmp/10k.ldif dc=example,dc=com … $ dsadm start /local/ds Server started: pid=8806 $ ldapsearch -D cn=Directory\ Manager -w - -p 1389 -b dc=example,dc=com \ objectclass=\* > /dev/null Enter bind password: $ pmap -x 8806 … Address Kbytes RSS Anon Locked Mode Mapped File … 0000000000437000 116644 109996 109780 - rw--- [ heap ] |
Here 10,000 entries occupy approximately 55 megabytes of entry cache memory (110 - 55).
As you move to 100,000 entries, you have more directory data to fit into database and entry caches. Initially, import 100,000 entries and examine the size required on disk for this volume of directory data.
$ dsadm import -i /local/ds /var/tmp/100k.ldif dc=example,dc=com … $ du -hs /local/ds 196M /local/ds |
Directory data contained in the database for our example suffix, dc=example,dc=com, now occupy about 142 megabytes.
$ du -hs /local/ds/db/example/ 142M /local/ds/db/example |
You can increase the size of the database cache to hold this content. If you expect the volume of directory data to grow over time, you can set the database cache larger than currently necessary. You can also set the entry cache size larger than necessary. Entry cache grows as the server responds to client requests, unlike the database cache, which is allocated at startup.
$ dsconf set-server-prop db-cache-size:200M $ dsconf set-suffix-prop dc=example,dc=com entry-cache-size:2G $ dsadm stop /local/ds Server stopped $ dsadm start /local/ds Server started: pid=8640 $ pmap -x 8640 … Address Kbytes RSS Anon Locked Mode Mapped File … 0000000000437000 61348 55404 55148 - rw--- [ heap ] … ---------------- ---------- ---------- ---------- ---------- total Kb 491984 485736 174620 - |
This shows the server instance has a relatively small heap at startup, but that the database cache memory has been allocated. Process size is nearing half a gigabyte.
$ ldapsearch -D cn=Directory\ Manager -w - -p 1389 -b dc=example,dc=com \ objectclass=\* > /dev/null Enter bind password: $ pmap -x 8640 … Address Kbytes RSS Anon Locked Mode Mapped File … 0000000000437000 610212 604064 603840 - rw--- [ heap ] … ---------------- ---------- ---------- ---------- ---------- total Kb 1040880 1034428 723360 - |
Heap size now reflects the entry cache being filled. It has increased by roughly 550 megabytes for 100,000 small directory entries, whose LDIF occupied 57 megabytes on disk.
With five extra indexes, the process size is about the same. The database cache size has not changed.
$ dsconf create-index dc=example,dc=com employeeNumber street st \ postalCode description $ dsadm stop /local/ds Server stopped $ dsadm import -i /local/ds /var/tmp/100k.ldif dc=example,dc=com … $ dsadm start /local/ds Server started: pid=8762 $ ldapsearch -D cn=Directory\ Manager -w - -p 1389 -b dc=example,dc=com \ objectclass=\* > /dev/null Enter bind password: $ pmap -x 8762 … Address Kbytes RSS Anon Locked Mode Mapped File … 0000000000437000 610212 603832 603612 - rw--- [ heap ] … ---------------- ---------- ---------- ---------- ---------- total Kb 1040876 1034192 723128 - |
The database is somewhat larger, however. The additional indexes increased the size of the database from 142 megabytes to 163 megabytes.
$ du -hs /local/ds/db/example/ 163M /local/ds/db/example |
As you move from 100,000 entries to 1,000,000 entries, you no longer have enough space on a system with 4 gigabytes of physical memory to include all entries in the entry cache. You can begin by importing the data and examining the size it occupies on disk.
$ dsadm import -i /local/ds /var/tmp/1M.ldif dc=example,dc=com … $ du -hs /local/ds/db/example/ 1.3G /local/ds/db/example |
Assuming you expect approximately 25% growth in directory data size during the lifetime of the instance, set the database cache size to 1700 megabytes.
$ dsadm start /local/ds Server started: pid=9060 $ dsconf set-server-prop db-cache-size:1700M $ dsadm stop /local/ds Server stopped $ dsadm start /local/ds Server started: pid=9118 $ pmap -x 9118 … Address Kbytes RSS Anon Locked Mode Mapped File … 0000000000437000 65508 55700 55452 - rw--- [ heap ] … ---------------- ---------- ---------- ---------- ---------- total Kb 1882448 1034180 76616 - |
Given a database cache this large and only 4 gigabytes of physical memory, you cannot fit more than a fraction of entries into the entry cache for the suffix. Here, set entry cache size to one gigabyte, and then prime the cache to see the change in the process heap size.
$ dsconf set-suffix-prop dc=example,dc=com entry-cache-size:1G $ ldapsearch -D cn=Directory\ Manager -w - -p 1389 -b dc=example,dc=com \ objectclass=\* > /dev/null Enter bind password: $ pmap -x 9118 … Address Kbytes RSS Anon Locked Mode Mapped File … 0000000000437000 1016868 1009852 1009612 - rw--- [ heap ] … ---------------- ---------- ---------- ---------- ---------- total Kb 2883268 2477064 1080076 - |
Total process size is over 2.8 gigabytes.
$ prstat -p 9118 PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP 9118 myuser 2816M 2374M sleep 59 0 0:03:26 0.5% ns-slapd/42 |
Extrapolating from earlier entry cache sizes, you can expect to use 5.5 or 6 gigabytes for entry cache alone if you had enough physical memory.
Examining the directory database size with five additional indexes, you find adding indexes has increased the size of the database by about 200 megabytes.
$ dsconf create-index dc=example,dc=com employeeNumber street st \ postalCode description $ dsadm stop /local/ds Server stopped $ dsadm import -i /local/ds /var/tmp/1M.ldif dc=example,dc=com … $ du -hs /local/ds/db/example 1.5G /local/ds/db/example |
Table 6–3 records what was observed in this example. It includes neither server process size, nor default database cache file size.
Your observations made through empirical testing for your deployment are likely to differ significantly from those shown here.
Number of Entries |
LDIF File Size |
Disk with Default Indexes |
Disk with Five Additional Indexes |
Database Cache |
Entry Cache |
---|---|---|---|---|---|
n/a |
n/a |
n/a |
n/a |
n/a |
|
10,000 |
5.7 megabytes |
19 megabytes |
26 megabytes |
32 megabytes |
55 megabytes |
100,000 |
57 megabytes |
142 megabytes |
163 megabytes |
200 megabytes |
550 megabytes |
1,000,000 |
573 megabytes |
1300 megabytes |
1500 megabytes |
1700 megabytes (default indexing) |
n/a |
In an actual deployment, you may have significantly larger entries and more indexed attributes. Do your own empirical testing and tuning before ordering hardware.
Default system settings do not necessarily result in top directory service performance. This section addresses how to tune the operating system for top performance.
See Sun Java System Directory Server Enterprise Edition 6.2 Release Notes for an updated list of supported operating systems.
You want to maintain overall system security. You also want to ensure proper Directory Server operation. You therefore install the latest recommended system patches, service packs, or fixes. See Sun Java System Directory Server Enterprise Edition 6.2 Release Notes for an updated list of the latest patches to apply for your platform.
The recommendations in this section do not eliminate all risk. Instead, the recommendations are intended as a short checklist to help you limit typical security risks.
Isolate and firewall the system. If at all possible, isolate the system where Directory Server runs from the public Internet with a network firewall.
Do not allow dual boot. Do not run other operating systems on the system that runs a production Directory Server. Other systems can permit access to files, which you should not allow.
Use strong passwords. Use a root password at least eight characters long. The password should include punctuation or other non-alphabetic characters.
You can use the Strong Password Check server plug-in to refuse weak passwords. The dsconf server property pwd-strong-check-enabled can be used to turn the plug-in on.
If you choose to use longer operating system passwords, you might have to configure the way passwords are handled by the system. See your operating system documentation for instructions.
Use a safe user and group ID for the server. For security reasons, do not run Directory Server with super user privileges.
You can, for example, use the UNIX commands groupadd and useradd to create a user and group without login privileges. You can then run the server as this user and group.
For example, to add a group that is named servers, do the following.
# groupadd servers |
To add a user named server1 as a member of the group servers, use the following command.
# useradd -g servers -s /bin/false -c "server1" |
A particular deployment can call for sharing Directory Server files with other servers, such as a messaging server. In such a deployment, consider running the servers with the same user, group ID.
Use the core facility. To facilitate debugging, you can allow processes running with this user, group ID to dump core. Use a utility such as the Solaris command coreadm. For example, you can enable Directory Server to generate core files by allowing setuid processes to do so, and updating the coreadm configuration:
# coreadm -e proc-setid # coreadm -u |
When scripting server startup, you can add the following line to your startup script. The line allows Directory Server to generate core files of the form core.ns-slapd.pid, where pid is the process ID.
coreadm -p core.%f.%p $$
Disable unnecessary services. For top performance with less risk, dedicate the system to Directory Server. As explained elsewhere in this guide, do not run Directory Service Control Center on the same system. When you run additional services, especially network services, you negatively affect server performance and scalability. You can also thereby increase security risks.
Disable as many network services as possible. Directory Server does not require file sharing and other services. Disable services such as IP Routing, Mail, NetBIOS, NFS, RAS, Web Publishing, and Windows Network Client services. Consider disabling telnet, and ftp.
As with many network services, telnet and ftp pose security risks. These two services are particularly dangerous, because the commands transmit user passwords in clear text over the network. Work around the need for telnet and ftp by using clients such as Secure Shell, ssh, and Secure FTP, sftp, instead. See your operating system documentation for details on disabling network services.
If the Directory Server instance does not provide the naming service for the network, consider enabling a naming service for the system. Directory Server then uses the naming service for example when resolving ACIs.
Ensure the system clock is reasonably in sync with other systems. Good clock synchronization facilitates replication. Good synchronization also facilitates correlation of date and time stamps in log files between systems. Consider using a Network Time Protocol, NTP, client to set the correct system time.
You can enable a server instance to restart at system boot time by using the dsadm command. For example, use the dsadm enable-service command on Solaris 10 and Windows systems. On other systems, use the dsadm autostart command. If you did not install from native packages, refer to your operating system documentation for help ensuring the server starts at system boot time.
When possible, stop Directory Server with the dsadm command, or from DSCC. If the Directory Server is stopped abruptly during system shutdown, there is no way to guarantee that all data has been written to disk correctly. When Directory Server restarts, it must therefore verify the database integrity. This process can take some time.
Furthermore, consider using a logging option with your file system. File system logging generally both improves write performance, and also decreases the time required to perform a file system check. The system must check the file system when the file system is not cleanly unmounted during a crash. Also, consider using RAID for storage.
The idsktune(1M) utility that is provided with the product can help you diagnose basic system configuration shortcomings. The utility offers recommendations for tuning the system to support high performance directory services. The utility does not actually implement any of the recommendations. The recommendations should be implemented by a qualified system administrator.
When you run the utility as root, idsktune gathers information about the system. The utility displays notices, warnings, and errors with recommended corrective actions. The idsktune command checks the following.
Operating system and kernel versions are supported for this release.
Available memory, and available disk space meet minimum requirements for typical use.
System resource limits meet minimum requirements for typical use.
Required patches are installed.
Fix at minimum all ERROR conditions before installing Directory Server software on a system intended for production use.
Individual deployment requirements can exceed minimum requirements. You can provide more resources than the resources identified as minimum system requirements by the idsktune utility.
Consider local network conditions and other applications before implementing specific recommendations. Refer to the operating system documentation for additional tips on tuning network settings.
Directory Server uses file descriptors when handling concurrent client connections. A low maximum number of file descriptors that are available for the server process can thus limit the number of concurrent connections. Recommendations that concern the number of file descriptors therefore relate to the number of concurrent connections Directory Server can handle.
On Solaris systems, the number of file descriptors available is configured through the rlim_fd_max parameter. Refer to the operating system documentation for further instructions on modifying the number of available file descriptors.
Specific network settings depend on the platform. On some systems, you can enhance Directory Server performance by modifying TCP settings.
First deploy your directory service, then consider tuning these parameters, if necessary.
This section discusses the reasoning behind idsktune recommendations that concern TCP settings, and provides a method for tuning these settings on Solaris 10 systems.
Some systems allow you to configure the interval between transmission of keepalive packets. This setting can determine how long a TCP connection is maintained while inactive and potentially disconnected. When set too high, the keepalive interval can cause the system to use unnecessary resources to keep connections for clients that have become disconnected. For most deployments, set this parameter to a value of 600 seconds. This value, which is 600,000 milliseconds, or 10 minutes, allows more concurrent connections to Directory Server.
When set too low, however, the keepalive interval can cause the system to drop connections during transient network outages.
On Solaris systems, this time interval is configured through the tcp_keepalive_interval parameter.
Some systems allow you to configure how long a system waits for an outgoing connection to be established. When set too high, establishing outgoing connections to destination servers such as replicas not responding quickly can cause long delays. For Intranet deployments on fast, reliable networks, you can set this parameter to a value of 10 seconds to improve performance. Do not, however, use such a low value on networks with slow, unreliable, or WAN connections, however.
On Solaris systems, this time interval is configured through the tcp_ip_abort_cinterval parameter.
Some systems allow you to configure the initial time interval between retransmission of packets. This setting affects the wait before retransmission of an unacknowledged packet. When set too high, clients can be kept waiting on lost packets. For Intranet deployments on fast, reliable networks, you can set this parameter to a value of 500 milliseconds to improve performance. Do not, however, use such a low value on networks with round trip times of more than 250 milliseconds.
On Solaris systems, this time interval is configured through the tcp_rexmit_interval_initial parameter.
Some systems allow you to configure how the system handles initial sequence number generation. For extranet and Internet deployments, set this parameter so initial sequence number generation is based on RFC 1948 to prevent sequence number attacks. In such environments, other TCP tuning settings mentioned here are not useful.
On Solaris systems, this behavior is configured through the tcp_strong_iss parameter.
On Solaris 10 systems, the simplest way to tune TCP settings is to create a simple SMF service as follows:
Create an SMF profile for Directory Server tuning.
Edit the following xml file according to your environment and save the file as /var/svc/manifest/site/ndd-nettune.xml.
<?xml version="1.0"?> <!DOCTYPE service_bundle SYSTEM "/usr/share/lib/xml/dtd/ service_bundle.dtd.1"> <!-- ident "@(#)ndd-nettune.xml 1.0 04/09/21 SMI" --> <service_bundle type='manifest' name='SUNWcsr:ndd'> <service name='network/ndd-nettune' type='service' version='1'> <create_default_instance enabled='true' /> <single_instance /> <dependency name='fs-minimal' type='service' grouping='require_all' restart_on='none'> <service_fmri value='svc:/system/filesystem/minimal' /> </dependency> <dependency name='loopback-network' grouping='require_any' restart_on='none' type='service'> <service_fmri value='svc:/network/loopback' /> </dependency> <dependency name='physical-network' grouping='optional_all' restart_on='none' type='service'> <service_fmri value='svc:/network/physical' /> </dependency> <exec_method type='method' name='start' exec='/lib/svc/method/ndd-nettune' timeout_seconds='3' /> </exec_method> <exec_method type='method' name='stop' exec=':true' timeout_seconds='3' > </exec_method> <property_group name='startd' type='framework'> <propval name='duration' type='astring' value='transient' /> </property_group> <stability value='Unstable' /> <template> <common_name> <loctext xml:lang='C'> ndd network tuning </loctext> </common_name> <documentation> <manpage title='ndd' section='1M' manpath='/usr/share/man' /> </documentation> </template> </service> </service_bundle>
Before you import the ndd-nettune.xml configuration, verify that the syntax is correct. You can do this by running the following command:
$ svccfg validate /var/svc/manifest/site/ndd-nettune.xml |
Import the configuration by running the following command:
$ svccfg import /var/svc/manifest/site/ndd-nettune.xml |
For more information see the svccfg(1M) man page.
Copy the following shell script into /lib/svc/method/ndd-nettune.
#!/sbin/sh # # ident "@(#)ndd-nettune.xml 1.0 01/08/06 SMI" . /lib/svc/share/smf_include.sh . /lib/svc/share/net_include.sh # Make sure that the libraries essential to this stage of booting can be found. LD_LIBRARY_PATH=/lib; export LD_LIBRARY_PATH echo "Performing Directory Server Tuning..." >> /tmp/smf.out /usr/sbin/ndd -set /dev/tcp tcp_conn_req_max_q 1024 /usr/sbin/ndd -set /dev/tcp tcp_keepalive_interval 600000 /usr/sbin/ndd -set /dev/tcp tcp_ip_abort_cinterval 10000 /usr/sbin/ndd -set /dev/tcp tcp_ip_abort_interval 60000 # Reset the library path now that we are past the critical stage unset LD_LIBRARY_PATH
Run svcadm to enable nettune (for more information, see the svcadm(1M) man page).
Run svcs -x (for more information see the svcs(1) man page).