| Performance tuning of any software application is a complex job. It requires you to have an understanding of various components and subsystems of the software and knowledge of operating system and other system resources, such as file system, memory, storage media, and bandwidth. eDirectory is no exception. Previous sections in this chapter cover many eDirectory-specific tuning tricks. There are also some operating system “specific performance enhancements you can make on Unix systems, and they are covered in the following sections. TIP If you are looking for a tool to help you tune a Unix system, SarCheck may be of use to you. It is a Unix performance analysis and tuning tool for most Sun Solaris, HP -UX, AIX, SCO, and Linux (in beta, at the time of this writing) systems that produces recommendations and explanations with supporting graphs and tables. Visit www.sarcheck.com/index.htm for more information.
TIP On high-end Solaris servers with many processors, it is better to create processor sets of not more than four and bind an instance of ndsd to the set. ndsd can then exploit warm on-chip caches to speed up operations.
Rather than go into the details for each supported Unix operating system, which would take a considerable amount of space, we refer you to Novell's eDirectory documentation and its whitepaper on eDirectory performance tuning for Linux and Unix systems (www.novell.com/products/edirectory/whitepapers.html) for specifics. The following sections describe the salient points that are common to the supported Unix operating systems. The Cache Subsystem eDirectory can dynamically adjust its cache limit to regulate memory consumption in response to the memory demand of other processes. The limit is calculated as a percentage of available physical memory at set intervals. Although this works well for NetWare and Windows servers, it is not recommended for Linux and Unix platforms. Large differences in memory usage patterns and memory allocators do not allow for optimal performance of eDirectory on these operating systems. On Unix systems (including Linux, unless otherwise specified), the free available memory reported by the operating system will be less than that for other operating systems because of the way the operating system uses free memory for internal caching of file system blocks, frequently run programs, libraries, and so on. In addition to this memory allocation, libraries on Unix normally do not return the freed memory back to the operating system. For these reasons, it is best to employ the Hard Limit mode and allocate a fixed amount of RAM to the eDirectory cache. NOTE On Unix/Linux, the operating system tries to cache file system blocks in its internal buffer cache. You should tune the operating system to flush this internal buffer cache as fast as possible ”and even bypass it completely, if possible. If bypassing the internal cache is not an option, you should not specify more than 50% to 75% of the total physical memory for the eDirectory cache.
eDirectory Threads eDirectory uses an internal pool of threads to service client requests and internal operations. This thread pool avoids the overhead of starting or stopping a new thread for every request. Maximum performance is achieved by using the minimum number of threads required to service the requests . The lower the number of threads, the fewer system resources are required to manage them. eDirectory 8.7 and later automatically use a lower number of threads and start or stop threads as needed. This delivers optimum performance in most cases; however, it may need to be tuned to handle sudden heavy client loads. You can place four parameters in the /etc/nds.conf file to help with tuning the thread requirements: -
n4u.server.active-interval controls when a new thread is started. A thread is considered busy on another job if it does not return to the thread pool within the time interval (in milliseconds ) specified by the parameter. This parameter is scaled based on the number of processors available on the machine and can be increased to its maximum value (25,000) to get the maximum performance. -
n4u.server.idle-threads specifies the minimum number of threads (regardless of activity) in the thread pool. The value of this parameter should be based on the average client load in order to minimize the time required to produce new threads during normal client activity. -
n4u.server.start-threads specifies the number of threads that get created and placed in the thread pool when eDirectory starts. The value of this parameter should be based on the average client load in order to minimize the time required to produce new threads during normal client activity. -
n4u.server.max-threads specifies the maximum number of threads to be created. Each thread uses about 200KB of memory when performing heavy searches. The value of this parameter should be based on the maximum number of simultaneous clients that need to be serviced, along with the following recommendations: -
eDirectory requires a minimum of 16 threads for its internal operations. -
There should be one Monitor thread for every 255 LDAP client connections. -
There should be one Worker thread for every four concurrent clients that need to be serviced. -
There should be eight threads for every processor configured to service client search requests. The default value for this parameter is 64 , and a value of 128 is sufficient in most cases, except when the server is serving a very large number of clients concurrently. File System As with the case of a disk subsystem and its configuration, the choice of the file system can significantly influence the performance of bulk updates; search performance is less affected because of the rather aggressive caching in eDirectory. One of the great things about Unix systems is the diverse choice of file systems that is available. Each has its own strengths and weaknesses, depending on your requirement. This is also one of the "bad" things about Unix: There are too many different file systems to choose from. NOTE There are complete books, not just chapters, written about Unix/Linux file systems. If you are interested in more information, take a look here: www.linuxshelf.com/servlet/books?category=filesystem.
If it's available for your Unix operating system, Novell recommends using the VERITAS file system with a block size of 4KB (the eDirectory database block size) because it can give significantly improved performance over "standard" Unix file systems. For HP-UX, Novell recommends that you use the JFS (VxFS) partition for storing the DIB directory. The default database block size of 4,096 bytes provides better performance for HP-UX. NOTE The VERITAS file system is a quick-recovery, journaling file system that is similar in some ways to Novell's NSS implementation. You can find more information about the VERITAS file system at www.veritas.com/products/category/ProductDetail.jhtml?productId=filesystem.
| 