|
| |
| Sun Java(TM) System Directory Server 5 2004Q2 Performance Tuning Guide | |
Chapter 2
Tuning the Operating SystemDefault system and network settings may not be ideal for top directory service performance. When tuning the underlying operating system for optimum Directory Server performance, you should check that the latest recommended patches are installed on the system, enforce basic security measures, and adjust some system and network settings. This chapter addresses those tuning options.
The idsktune utility (directoryserver -u 5.2 idsktune) provided with the product may help you to diagnose basic system configuration shortcomings. The utility offers system tuning recommendations for support of high performance directory services. The utility does not actually implement any of the recommendations made. Tuning recommendations should be implemented by a qualified system administrator.
This chapter covers the following topics:
Checking Platform SupportRefer to the Directory Server Release Notes for an updated list of supported platforms.
Patching the SystemIn order to maintain overall system security, and to ensure proper installation and operation of Directory Server 5.2, install the latest recommended system patches, service packs, or fixes. Table 2-1 suggests where to look for required patches.
Table 2-1 Where to Obtain Patches, By Platform
Platform
Browse...
Sun Solaris™ Operating System
Red Hat Linux
Enforcing Basic SecurityThe recommendations in this section do not eliminate all risk. Instead, they are intended as a short checklist to help you work to limit some of the most obvious security risks.
Isolate the System
If at all possible, isolate the system running Directory Server from the public Internet using a network firewall.
No Dual Boot
Do not dual boot or run other operating systems on the system running Directory Server. Other systems may permit access to otherwise restricted files.
Strong Passwords
Use a super user password at least 8 characters long that includes punctuation or other non-alphabetic characters.
If you choose to use longer operating system passwords, it may be necessary to configure the way passwords are handled by the system. Refer to the operating system documentation for instructions.
Users and Groups
For security reasons, it is recommended not to run Directory Server or the associated Administration Server with super user privileges. You may, for example, create a user and group without login privileges, and then install and run the servers as this user and group. If you add the user and group to local files the /etc/passwd entry could be, for example:
server:x:61001:61001:Server User:/dev/null:/dev/null
The corresponding /etc/group entry could be, for example:
servers:x:61001:
To facilitate debugging, you may choose to allow processes running with this user and group identity to dump core, using utilities such as coreadm(1M) on Solaris systems. For example, you can enable Directory Server running as this user and group to generate core files by allowing setuid processes to do so, and updating the coreadm configuration:
# coreadm -e proc-setid
# coreadm -uFurthermore, by adding the following line near the top of the ServerRoot/slapd-serverID/start-slapd script, you allow Directory Server to generate core files of the form core.ns-slapd.pid, where pid is the process ID:
coreadm -p core.%f.%p $$
If a particular deployment calls for sharing Directory Server files with other servers such as a messaging server, consider running those servers using the same user and group.
If you must run the Administration Server as super user, consider stopping the service when not using it. You must start the Administration Server again before you can use the Console, which depends on Administration Server running.
Disabling Unnecessary Services
For top performance and less risk, dedicate the system to Directory Server alone. Running additional services, especially network services, negatively affects server performance and scalability, and may increase security risks.
Disable as many network services as possible. Directory Server uses only TCP/IP, and UDP/IP if you run SNMP agents. It 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 in that they transmit user passwords in clear text over the network. You may be able to work around the need telnet and ftp by using clients such as Secure Shell (ssh) and Secure FTP (sftp) instead.
If the Directory Server instance does not itself provide the naming service for the network, consider enabling a naming service for the system, which Directory Server then uses for example when resolving ACIs. Remote administration tools such as Sun Java System Server Console rely on the naming service for some aspects of their operation such as translating between IP addresses and host names.
Refer to the operating system documentation for details on disabling network services.
Keeping Accurate TimeEnsure the system clock is reasonably in sync with those of other systems to facilitate replication and 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, for example.
Restarting After System FailureWhen possible, stop Directory Server as described in the Directory Server Administration Guide. Database corruption may cause Directory Server to start slowly if stopped abruptly during system shutdown, rather than shut down appropriately. Time may be needed to recover the database.
Consider using a logging option with your file system, which generally both improves write performance and decrease the time required to perform a file system check when the file system is not cleanly unmounted as is typically the case during a crash. Also consider using RAID, as described in the Directory Server Administration Guide.
As part of the installation and configuration process, appropriate scripts enable restart at boot time.
For other platforms, refer to the operating system documentation for details on starting services at boot time.
Generating Basic Tuning RecommendationsUse the idsktune utility (directoryserver -u 5.2 idsktune) to generate basic tuning recommendations.
When you run the utility as super user, it gathers information about the system. It displays notices, warnings, and errors with recommended corrective actions. For example, the utility checks that:
Individual deployment requirements may exceed minimum requirements. You may opt to provide more resources than those identified as minimum system requirements by the idsktune utility.
Refer to the Sun Java System Directory Server Resource Kit documentation for details concerning the utility. The Sun Java System Directory Server Resource Kit can be obtained as described in Resources and Tools on the Web.
Tuning System SettingsYou may use the idsktune tool that reads current system settings and recommends changes. In general, implementing the recommendations optimizes performance both on systems dedicated to running Directory Server and on systems running additional applications.
Consider local network conditions and other applications before implementing specific recommendations. Refer to the operating system documentation for additional network tuning tips.
File Descriptors
Directory Server uses file descriptors when handling concurrent client connections. Having a low maximum number of file descriptors available in the system or available to a process can thus limit the number of concurrent connections. Recommendations concerning the number of file descriptors therefore relate to the number of concurrent connections Directory Server may be able to handle on the system.
On Solaris systems, the number of file descriptors available is configured through the rlim_fd_max parameter, as described in the output of directoryserver -u 5.2 idsktune. Refer to the operating system documentation for further instructions on modifying the number of available file descriptors.
After modifying the maximum number of available file descriptors on the system, refer to Table 6-2 for information on configuring Directory Server to use the available file descriptors.
Transmission Control Protocol (TCP) Settings
Specific network settings depend on the platform. On some systems, it is possible to enhance Directory Server performance by modifying TCP settings. This section discusses the reasoning behind idsktune recommendations concerning TCP settings.
Closed Connections in the TIME-WAIT State
Some systems allow you to configure how long a TCP connection is held in the kernel table after closure. While the connection is held, it may be opened again quickly. When set too high, the system may track a large number of connections in the kernel table over long intervals, reducing the number of available connections to Directory Server. For most deployments, setting this parameter to a value of 30 seconds (30,000 milliseconds) allows more concurrent connections to Directory Server.
On Solaris systems, this time interval is configured through the tcp_time_wait_interval parameter, as described in the output of directoryserver -u 5.2 idsktune.
Connections Pending Acceptance
Some systems allow you to configure the number of TCP connections pending acceptance by a TCP listener such as Directory Server. When set too low, this limits the number of pending connections Directory Server can accept. For most deployments, setting this parameter to a value of at least 1024 allows Directory Server to handle more concurrent connection requests.
On Solaris systems, the number of pending connections allowed is configured through the tcp_conn_req_max_q0 parameter, as described in the output of directoryserver -u 5.2 idsktune. Consider increasing tcp_conn_req_max_q0 to 2048.
Inactive Connections
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 may cause the system to use unnecessary resources keeping connections alive for clients that have become disconnected. For most deployments, setting this parameter to a value of 600 seconds (600,000 milliseconds = 10 minutes) allows more concurrent connections to Directory Server.
On Solaris systems, this time interval is configured through the tcp_keepalive_interval parameter, as described in the output of directoryserver -u 5.2 idsktune.
Incoming Connections
Some systems allow you to configure how long a system waits for an incoming connection not sending acknowledgements. When set too high, this can cause long delays in detecting connection failure. For intranet deployments on fast and reliable networks, setting this parameter to a value of 600 seconds (600,000 milliseconds = 10 minutes) may improve performance.
On Solaris systems, this time interval is configured through the tcp_ip_abort_interval parameter, as described in the output of directoryserver -u 5.2 idsktune.
Outgoing Connections
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 and reliable networks, setting this parameter to a value of 10 seconds may improve performance.
On Solaris systems, this time interval is configured through the tcp_ip_abort_cinterval parameter, as described in the output of directoryserver -u 5.2 idsktune.
Retransmission Timeout
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 may be kept waiting on lost packets. For intranet deployments on fast and reliable networks, setting this parameter to a value of 500 milliseconds may improve performance.
On Solaris systems, this time interval is configured through the tcp_rexmit_interval_initial parameter, as described in the output of directoryserver -u 5.2 idsktune.
Sequence Numbers
Some systems allow you to configure how the system handles initial sequence number generation. For extranet and Internet deployments, set this parameter such that initial sequence number generation is based on RFC 1948 to prevent sequence number attacks.
On Solaris systems, this behavior is configured through the tcp_strong_iss parameter, as described in the output of directoryserver -u 5.2 idsktune.