White PapersThis method dynamically adjusts the cache limit to regulate memory consumption. A dynamically adjusting limit causes eDirectory to periodically adjust its memory consumption in response to the flow of memory consumption by other processes. You need to specify the limit as a percentage of the available physical memory.
Using this percentage, eDirectory recalculates a new memory limit at fixed intervals. While this works well in typical user scenarios, because of large differences in memory usage patterns and memory allocators on UNIX platforms, this mechanism is not recommended for optimal performance of eDirectory on UNIX platforms.
www.novell.comGU I D ENovell eDirectory"8.7:Performance Tuning for Linux* and UNIX*Untitled DocumentAB O U T T H I S G U I D EThis guide describes how to tune Novell eDirectory"on Linux* and UNIX*platforms to improve its performance, providing both eDirectory tuneablesand OS specific tuneables to optimize performance when deploying eDirectory.This guide is intended for network administrators.Documentation ConventionsIn this documentation, a greater-than symbol (>) is used to separate actionswithin a step and items within a cross-reference path.A trademark symbol ( , TM, etc.) denotes a Novell trademark. An asterisk(*) denotes a third-party trademark.When a single pathname can be written with a backslash for some platformsor a forward slash for other platforms, the pathname is presented with abackslash. Users of platforms that require a forward slash, such as UNIX, shoulduse forward slashes as required by your software.Untitled DocumentTable of Contents2278991010IN T R O D U C T I O NT U N I N G T H E C A C H E S U B S Y S T E MD ATA B A S E I N D E X I N GT U N E A B L E S F O R B U L K L O A D I N GD ATAT U N I N G A R E P L I C A R I N G F O RM I N I M U M R E P L I C AT I O NT U N I N G e D I R E C TO RY T H R E A D ST U N I N G F I L E S Y S T E MT U N I N G O P E R AT I N G S Y S T E M F O Re D I R E C TO RYNovell eDirectory 8.7: Performance Tuning for Linux and UNIXUntitled DocumentNovell eDirectory 8.7: Performance Tuning for Linux and UNIX2IntroductionNovell eDirectory"8.7 is a standards-compliant, cross-platform, highly scalable, fault-tolerant and high-performance directory service.Performance tuning of any software application is a complex job. It requires anunderstanding of various components and subsystems of the software, knowledge ofoperating system and other system resources like file system, memory, storage mediaand bandwidth.Prerequisites" Ensure that you are running Novell eDirectory8.7 with the latest patches and updates.To check the version of eDirectory, enter thefollowing command:ndsd --version" Ensure that your OS is updated with the latestpatch levels.Linux*: Red Hat* Linux 7.2 or 7.3Ensure that the latest glibc patches are applied from Red Hat Errata(http://www.redhat.com/apps/support/errata) on Red Hat systems.Solaris*: Solaris 7 on Sun* SPARC (with patch106327-13 or later for 32-bit systems) Solaris 7 on Sun SPARC (with patch106300-07 or later for 64-bit systems) Solaris 8 on Sun SPARC (with patch108827-20 or later)AIX*: AIX 4.3.3 with Maintenance Level 10,JVM* 1.3.1, and the latest AIX V5.0Runtime Libraries (http://www-1.ibm.com/support/docview.wss?uid=swg24001173) AIX 5L with Maintenance Level 2, JVM 1.3.1, and the latest AIX V6.0Runtime Libraries (http://www-1.ibm.com/support/docview.wss?uid=swg24001467)For more information about system require-ments, refer to the eDirectory AdministrationGuide at: http://www.novell.com/documentation/lg/edir87/index.html.T U N I N G T H E C A C H E S U B S Y S T E MNovell eDirectory uses a state-of-the-art cachesubsystem to reduce disk access and deliver betterperformance. Adequate amount of cache memoryis critical for the performance of eDirectory servers.Untitled DocumentHence, cache sizing is one of the most importantfactors affecting the overall performanceof eDirectory.This section describes how eDirectory uses thecache internally. Understanding this is importantfor tuning the cache for a specific deployment.Novell eDirectory 8.5 and later versions provide a block cache and an entry cache to boost certainareas of eDirectory performance.There is a certain amount of redundancybetween the two caches, but each cache isdesigned to boost performance for different typesof operations." The block cache holds the physical disk blocksto minimize frequent access to the disk;whereas, the entry cache contains logicalentries from the directory." Generally, block cache is more useful forupdate operations, and entry cache is moreuseful for operations that tend to browse ortraverse the directory tree by reading throughentries like name-resolution operations." Both block cache and entry cache are usefulin boosting query performance block cachehelps searching indexes, and entry cache helpsretrieving the entries that are referencedfrom an index." With both an entry cache and a block cache,the total memory available for caching iseffectively split between the two caches. By default, eDirectory splits the cache equallyby giving 50% of available cache to each cache.eDirectory normally creates logical entries inmemory by getting the data from the block cache.The entry cache reduces the processing timerequired to do this. This time saving can besignificant in some applications.The rule of the thumb here is that the largerthe number of items (blocks and entries) you cache,the better the overall performance. The ideal isto cache the entire database in both the entrycache and the block cache. This would not bepossible for extremely large databases.The amount of memory required to cache theentire database in the block cache is roughly thesize of the database on disk, which is a 1:1 ratio.On the other hand, the amount of memory neededto cache the entire database in the entry cache is roughly two to four times the database size ondisk, that is, a 1:2 or 1:4 ratio.NOTE: This is only a very broad and very generalrule of thumb and could vary significantly basedon your deployment. Set the cache between100MB to 2.5GB. You would not need more than three to four times the size of the DIB. For large DIBs, limit the cache to 2GB.In order to address the wide range of needsand different deployments and configurationspossible, the mechanisms for regulating cachememory consumption in eDirectory 8.7 have beenmade to be intelligent, dynamic, and automated.eDirectory provides the following two types ofmethods to control cache memory consumption:" Dynamic Sizing of the Cache " Hard Memory Limit Both of these methods are mutually exclusive.You can use either one at any time, but the lastone used always replaces any earlier settings.Novell eDirectory 8.7: Performance Tuning for Linux and UNIX3Untitled DocumentDynamic Sizing of the CacheThis method dynamically adjusts the cache limitto regulate memory consumption. A dynamicallyadjusting limit causes eDirectory to periodicallyadjust its memory consumption in response to theflow of memory consumption by other processes.You need to specify the limit as a percentage of theavailable physical memory. Using this percentage,eDirectory recalculates a new memory limit atfixed intervals. While this works well in typicaluser scenarios, because of large differences inmemory usage patterns and memory allocators onUNIX platforms, this mechanism is not recommendedfor optimal performance of eDirectory on UNIX platforms. UNIX gives the impression of having lessavailable memory than other operating systemsbecause of the following reasons:" UNIX uses the free memory for internalcaching of file system blocks, frequently runprograms, libraries, etc." Libraries in UNIX normally do not return thefreed memory back to the OS.NOTE: Physical memory excludes machine swapspace. This convention is followed throughout this document.Hard Memory LimitThis is the second method provided for regulatingmemory consumption. The Hard Memory Limit was present in earlier versions of eDirectory also.Once this is set, a limit is not changed until youeither set a different hard limit or dynamicallyadjust the limit.You are allowed to specify a hard memory limit in one of three ways:" Method 1: As a fixed number of bytes" Method 2: As a percentage of physicalmemory" Method 3: As a percentage of availablephysical memoryA hard limit specification using the second and third methods is always translated to a fixednumber of bytes. Thus, for method two, the numberof bytes will be the percentage of physical memorythat is detected when eDirectory is started. For method three, the number of bytes will be the percentage of available physical memory that is detected when eDirectory queries the OS at regular intervals of time.The default mechanism for regulating memory consumption is as follows: if the servercontains a replica, eDirectory uses a dynamically adjusting limit of 51% of available memory, with a minimum of 8 megabytes, leaving aminimum of 24 megabytes for other applications.Otherwise, eDirectory uses a hard limit setting of 16 megabytes, with 8 megabytes for blockcache and 8 megabytes for entry cache.Interaction of File System Buffer CacheOn UNIX platforms, the OS tries to cache file systemblocks in its internal buffer cache. You mustnormally tune the OS to flush this internal buffercache as fast as possible; even bypass it completely,if it is feasible. If this is not possible, do notspecify more than 50-75% of the total physicalmemory for the eDirectory cache.Novell eDirectory 8.7: Performance Tuning for Linux and UNIX4Untitled Documentthat can be created or modified with any texteditor. The syntax for controlling cache memoryconsumption is given in the sections below. NOTE: Although you may alter the _ndsdb.ini file at any time, the changes do not take effect in eDirectory until the server is restarted.Set the Hard Memory LimitAdd the following line to the _ndsdb.ini file to setthe maximum amount of cache that eDirectorywill consume (including both the entry cache andthe block cache):cache=cache bytes>Set a Dynamically Adjusting LimitAdd the following line to the _ndsdb.ini file.cache=cache options>Dirty CacheNovell eDirectory 8.7 introduced a new methodfor specifying the maximum dirty cache and the low dirty cache for the eDirectory cache. The purpose is to keep the amount of dirty cacheat any given instant below a particular value. This value is configurable. This evens out the disk writing, instead of burdening the checkpointthread in the forced mode, which will essentiallywrite the whole cache to the disk, thereby creatingan I/O bottleneck.Refer to section Setting the Maximum andLow Dirty Cache on page 6 for more details.Database Tuneable Parameter SettingsAt startup, eDirectory looks for the databaseoptions file, _ndsdb.ini, in the directory the DIBfiles are stored in. This file is a simple text fileNovell eDirectory 8.7: Performance Tuning for Linux and UNIX5The cache options are described below. Multiple options may be specified, in any order, separated by commas:CACHE OPTIONSDESCRIPTIONDYN or HARDDynamically adjust the limit or hard limit. (For optimal performance use only hard on UNIXplatforms).NOTE: We recommend you to use HARD limits.%:Percentage of available or physical memory to use.AVAIL or TOTALPercentage is for the available physical memory or total physical memory. This option is ignored fora dynamically adjusting limit, because a dynamically adjusting limit is always calculated based onthe available physical memory.MIN:Minimum number of bytes.MAX:Maximum number of bytes.LEAVE:Minimum number of bytes to leave for the OS and other applications.Untitled DocumentExamples:" Set cache to 75% of total memory, minimumof 16 megabytes as follows:cache=HARD,%:75,MIN:16000000" Set cache to 65% of total memory, leaving atleast 32 megabytes for the OS, minimum of 32 megabytescache=HARD,%:65,MIN:32000000,LEA VE:32000000Setting the Cache Adjust Interval and CacheCleanup IntervalIn addition to the cache setting for regulatingmemory consumption, eDirectory also providessettings to control the dynamic adjust interval,and the interval for cleaning up older versions ofentries and blocks.These settings are as follows:cacheadjustinterval=seconds>cachecleanupinterval=seconds>Default is 15 seconds, if it is not set in the .ini file.Setting the Cache RatiosThe following setting allows you to control thepercentage split between the entry and block cache:blockcachepercent=percent>Default is 50 percent, if it is not set in the .ini file.Where, percent> should be a value between 0 and 100 (inclusive).A value of 70 means that 70 percent of cachememory would be used for block cache and 30 percent for entry cache.We do not recommend you to set thispercentage to 0.Set blockcachepercent between 70% and 90%depending on the proportion of updates in thetotal operations.Set it to 90% for operations like bulk create or delete.Set to 50% if you do not expect too manyupdate bursts.Setting the Database Block SizeNovell eDirectory uses a default database blocksize of 4096 bytes. In FLAIM, block is a buffer usedto aggregate disk images of an entry. It is used tomodel a portion of a single file on disk. Larger theblock, more the number of entries in a block andlonger is the time taken to search within a blockand extract an entry. But a short block meansmore I/O calls to the OS. You can configure the database block size as follows:blocksize=4096 or 8192>Note that this parameter is effective onlyduring the installation of eDirectory and has noeffect once a database has been created. It is also important to understand that increasing theblocksize from 4096 may adversely impact theperformance of other eDirectory operations (like search) even though update performance will improve. A block size of 4K gives betterperformance in all cases.Setting the Maximum and Low Dirty CacheThe two parameters we recommend to set whilebulkloading the database are maxdirtycache andNovell eDirectory 8.7: Performance Tuning for Linux and UNIX6Untitled Documentlowdirtycache. You need to set them in the_ndsdb.ini file.eDirectory 8.7, by default sets the value ofmaxdirtycache to the unlimited value and thelowdirtycache value is set to zero.You can specify the maxdirtycache andlowdirtycache as follows:maxdirtycache=value>lowdirtycache=value>Modifying Database Cache Settings at RuntimeYou can set the amount of cache to be used while eDirectory is running by using the ndstraceutility. In the ndstrace window, enter thefollowing command:set dstrace=!mbamount of RAM to use in bytes>To set a simple hard limit, enter the followingcommand:set dstrace=!mbcache options>To set a dynamically adjusting limit, see Set aDynamically Adjusting Limit on page 5. The settingsare effective only as long as the current instanceof eDirectory is running.DATA B A S E I N D E X I N GTo improve the performance of LDAP searches,index the attributes on which a search is done.There are three types of indexes:" Presence" Value" SubstringYou can add an index using ConsoleOne .Indexes can dramatically speed up the performanceof applications based on the search expressionsbeing used. Indexes need to be created judiciously ,because, while indexes increase the searchperformance, each additional index adds to theupdate time for a new object; this is especiallytrue for substring. The Novell eDirectory databaseis set up to select one optimal index per complexsearch, and then apply the other filter criteria to the results pulled from the index.NOTE: For massive bulkloading (millions of objects),we do not recommend you to disable the eDirectoryserver indexes while bulkloading the directory.Suspending the IndexesWhen you are bulkloading a large amount ofobjects, you can suspend the substring indexes to speed up the bulk loading operation. You canenable them later after the loading is complete;eDirectory will automatically complete theindexing in the background. However, please note that the indexes will not be used for search operations until the background indexing iscomplete and the indexes are brought online.Bulkloading users with passwordsBulkloading users with passwords is much slowerthan adding users without passwords becauseeDirectory has to create a RSA* Key Pair for each password. This is a CPU-intensivecryptographic operation and cannot be bypassedbecause of the security needs of eDirectory. It isrecommended that you first start a bulkload ofthe users without password and add the passwordsin parallel.Novell eDirectory 8.7: Performance Tuning for Linux and UNIX7Untitled DocumentTU N E A B L E S F O R B U L K L O A D I N G D ATANovell Import Convert and Export (ICE) utility uses an optimized bulk update protocol calledLBURP to upload data into the directory eDirectory . This protocol is significantly faster than uploadingusing a simple ldapmodify command.NOTE: For faster bulkloading, use the -C -n optionswith ICE.n4u.ldap.lburp.transizeICE loads multiple objects in a single transactionto improve update performance. You can increasethe performance of ICE bulkload even further byincreasing the transaction size from the default of 25. The recommended range of this transactionsize is 25 to 350 depending on the size of thewhole transaction and system resources. However,note that an increase in the transaction size willincrease the memory usage in eDirectory becauseall the records must be buffered in memory. If thesystem is running low on memory, this can cause aslowdown due to swapping. The transaction sizecan be modified by specifying the required valuefor the n4u.ldap.lburp.transize parameter in the/etc/nds.conf file.The LBURP transaction size determines thenumber of records that will be sent from the ICEutility to the LDAP server in a single LBURP packet.However, even if a single error exists in thetransaction, (including cases where the object tobe added already exists in the directory), the LBURPoptimization will be disabled and objects will beadded to eDirectory individually for that transaction.In addition, the LBURP optimization currentlyworks only for leaf objects; so the optimization islost if the transaction contains both a container andit s subordinate objects. Therefore, we recommendyou to add the containers first, using a separateLDIF file.blockcachepercentWhen you are bulkloading a large number ofobjects (e.g. greater than one million), you canset the blockcachepercent parameter to 90% orhigher in the _ndsdb.ini file. Remember to changethe parameter back to the original value after you complete the bulkload.maxdirtycache and lowdirtycacheWhile loading a large number of objects, a burst in Disk I/O is observed, which slows down thebulkloading rate. To smoothen the disk I/O pattern we need to set the maxdirtycache andlowdirtycache to appropriate values.NOTE: Setting of maxdirtycache andlowdirtycache is useful only for bulkloading forless than 1.5 million objects. For higher values,there might be a performance degradation.Guidelines to Set the Value ofmaxdirtycache and lowdirtycacheMeasure the random I/O write speed to the diskand set the maxdirtycache such that all modifiedbuffers in a 3-minute interval can be flushed tothe DIB volume in ten seconds (10000ms) or lessand set lowdirtycache to about half this value.For example, if the random write speed is10ms per block (4KB), then set maxdirtycache to(10000ms*4K/10) or 4000KB. On most systems, Novell eDirectory 8.7: Performance Tuning for Linux and UNIX8Untitled Documentthe maxdirtycache will be between 1 and 10MB.Fibre Channel SANs offer higher rates, so you cango up to 20MB.If you are not sure, set it to 5MB and observethe max update response time during a burst ofupdates. Adjust this value upwards until theresponse time is acceptable. TU N I N G A R E P L I C A R I N G F O RM I N I M U M R E P L I C AT I O N L AT E N C YNovell eDirectory uses a slow, but sure convergencealgorithm to replicate changes on a single replicaserver to its peers in a replication ring. A replicaserver can manage only a single DIB, but a DIBmay contain replicas of multiple partitions.eDirectory uses a batch update mechanism for replication. The period for which changes areaccumulated in a replica server is adjustable from one second to a few hours, but defaults to 30 minutes.Important changes like passwords will schedulea sync immediately. However, sync operations arehandled by a background thread which would yieldor postpone its operation if a request for a create,modify or delete operation is received.Replication latencies can be minimized bypartitioning a tree such that update operationsare spread across multiple partitions and placingthese volatile partitions on DIBs such that thepeak update load on each DIB is minimized. For example, if a tree has three containers that are volatile, then isolate each container into a partition and place them in separate DIBs.Larger the peak update rate, smaller the ring, but a ring should be designed with at least twoDIBs. If the entire server farm is front-ended by a load balancing switch, configure the switch todirect all requests to the primary servers andfailover to the secondary.T U N I N G e D I R E C TO RY T H R E A D SNovell eDirectory uses an internal pool of threadsto service client requests and internal operations.This thread pool avoids the overhead of starting orstopping a new thread for every request. Maximumperformance is achieved by using the minimumnumber of threads required to service the requests.eDirectory 8.7 automatically tries to use a lessernumber of threads and starts or stops threads as needed. This delivers optimum performance inmost cases. This may need some tuning underheavy client loads.n4u.server.active-intervalThe parameter n4u.server.active-interval controlswhen a new thread is started. A thread should beconsidered busy on another job if it does not returnback to the thread pool within the time interval(in milliseconds) specified by the parameter. This parameter is scaled based on the number ofprocessors available on the machine and can beincreased to its maximum value (25000) to get the maximum performance.n4u.server.idle-threadsThis may be specified depending upon the averageclient load. The idea is to minimize the timerequired to produce new threads during normalclient activity. The parameter specifies the minimumnumber of threads regardless of any activity. Novell eDirectory 8.7: Performance Tuning for Linux and9Untitled Documentn4u.server.start-threadsThis specifies the number of threads that startwhen eDirectory starts. This also depends uponthe average client load, in order to minimize thetime required to produce new threads duringnormal client activity.n4u.server.max-threadsThe number of threads in eDirectory also influencesthe memory used by the process (in addition to thedatabase cache). Each thread uses approximately200 KB of memory during intensive search operations.As a general rule, assume that eDirectory willinternally need about 16 threads for its internaloperations. Add an additional thread for every 255clients that need to be serviced simultaneously.Finally, add approximately 8 threads for eachprocessor configured on the machine to serviceclient search requests (the actual number willdepend on the time taken for each request).Number of eDirectory server threads = 16 (needed internally by eDirectory)+ (Number of simultaneous clients servicerequests) / 255+ (8 * number of processors)Use this value to set the parametern4u.server.max-threads. A value of 128 works wellin most cases and will not require more tuningexcept when servicing a very large number ofclients. The default value for this parameter is 64.TU N I N G F I L E S Y S T E MThe choice of the file system can influence the bulkupdate performance significantly, though searchperformance is less affected because of aggressivecaching in Novell eDirectory. Using Veritas* File System with a block size of 4KB (eDirectorydefault database block size) can give significantlyimproved performance. If you are installing overUFS, you may also set the blocksize parameter to8192 in _ndsdb.ini.As mentioned earlier, dynamic resizing of theeDirectory database cache does not inter-operatewell with Solaris internal caching and the userlevel memory allocation algorithms. Therefore, we recommend that you always use a hard limitfor the cache to get optimal performance.T U N I N G O P E R AT I N G S Y S T E M F O R e D I R E C TO RYThe operating system on which Novell eDirectoryis installed plays a crucial part in its performance.This section gives general guidelines on tuningyour OS and then gives specific tuneables basedon your target platform.Operating System VersionThe version of the OS that you are running on may affect the performance of eDirectorysignificantly. In general, you must update your OSto the latest patch level and in some instancesupgrade to a newer version of your OS to getoptimal performance. For more information, see Prerequisites on page 2.Disk PerformanceUpdate operations in eDirectory can be diskintensive. Spread out the I/O bandwidth overNovell eDirectory 8.7: Performance Tuning for Linux and UNIX10Untitled Documentmultiple disks with RAID striping. You can have a stripe width of 16KB, 32KB, 64KB (based on your disk/controller) for maximum performance. The choice of the file system and the file systemblock size also affects performance.Tuning Solaris for eDirectoryNote that some of these parameters may besuperseded or modified for newer versions ofSolaris. This information applies for Solaris 7 and Solaris 8. Set the following system tuneables in the/etc/system file:set priority_paging=1 (Not needed on Solaris 8onwards)set maxphys=1048576set ufs:ufs_LW=set ufs:ufs_HW=set tcp:tcp_conn_hash_size=8192Ensure to backup your original file beforemaking these changes and to reboot your systemto get the parameters in effect." priority_paging. The priority paging algorithmallows the system to place a boundary aroundthe file cache, so that file system I/O doesnot cause paging of applications. Settingpriority_ paging value to 1 enables prioritypaging. You should not set the system variablepriority_paging in the Solaris 8 operatingenvironment, and you should remove thevariable from the /etc/system file whensystems are upgraded to the Solaris 8operating environment." maxphys. Maximum size of physical I/Orequests. It is specified when doing I/O to andfrom a UFS file system where large amountsof data (greater than 64 Kbytes) are beingread or written at any one time." ufs_HW. The number of bytes outstanding ona single files barrier value. If the number ofbytes outstanding is greater than this valueand ufs_WRITES is set, then the write isdeferred. The write is deferred by putting the thread issuing the write to sleep on acondition variable." ufs_LW. The barrier for the number of bytesoutstanding on a single file below which thecondition variable on which other sleepingprocesses is toggled. When a write completesand the number of bytes is less than ufs_LW,then the condition variable is toggled, whichcauses all threads waiting on the variable toawaken and try to issue their writes.ufs_LW and ufs_HW have meaning only if ufs_WRITES(set in /etc/system) is not equal to zero. ufs_HW and ufs_LW should bechanged together to avoid needless churningwhen processes awake and find that theyeither cannot issue a write (when ufs_LWandufs_HWare too close) or when they might havewaited longer than necessary (when ufs_LWandufs_HW are too far apart)." tcp_conn_hash_size. Controls the hash table size in the TCP module for all TCPconnections. If the system consistently has tensof thousands of TCP connections, increase theNovell eDirectory 8.7: Performance Tuning for Linux and UNIX11Untitled Documentvalue accordingly. With the default value, TCP performs well up to a few thousand activeconnections. Note that increasing the hashtable size means more memory consumptionso set an appropriate value to avoid wastingmemory unnecessarily. The parameter canonly be changed at boot time.The number of connections to an eDirectoryreplica also influences the search performance.Many improvements were made to makeeDirectory performance scalable with growingnumber of connections. However, many TCPparameters, like transmission and receptionqueue size and transmission and receptionwindow size, influence the behavior of thenetworking subsystem in the operating system.These may affect eDirectory performance. For optimizing search performance, set thefollowing networking tuneables using ndd:ndd -set /dev/tcp tcp_conn_req_max_q 1024ndd -set /dev/tcp tcp_close_wait_interval 60000(obsolete in Solaris 8 onwards, instead usetcp_time_wait_interval)ndd -set /dev/tcp tcp_xmit_hiwat 32768ndd -set /dev/tcp tcp_xmit_lowat 32768ndd -set /dev/tcp tcp_slow_start_initial 2NOTE: Please note that these ndd settingswill not survive a reboot. Please add them in ascript that will be run at boot time. You mayalso need to set these parameters on yourLDAP client machine to get the best results. tcp_conn_req_max_q. The defaultmaximum number of pending TCPconnections for a TCP listener waiting tobe accepted by accept. For applicationssuch as Web servers that might receiveseveral connection requests, the defaultvalue might be increased to match theincoming rate. tcp_xmit_hiwat. This is the default sendwindow size in bytes. tcp_close_wait_interval. The time inmilliseconds a TCP connection stays inTIME-WAIT state (tcp_close_wait_intervalis obsolete in Solaris 8 onward; usetcp_time_wait_interval in Solaris 8). On abusy Web server , there can be too manyTCP connections in TIME-WAIT state,consuming too much memory. In thissituation, you can decrease the value forperformance reasons. Do not set the value lower than 60 seconds. tcp_slow_start_initial. The maximuminitial congestion window (cwnd) size inMSS of a TCP connection. If the initialcwnd size causes network congestionunder special circumstances, decreasethe value.Tuning Linux for eDirectoryWe strongly recommend that you upgrade to Linuxkernel versions 2.4.9 or above for eDirectory.eDirectory performance is significantly better with 2.4.9 or above kernel versions, especially inlarge memory configurations.There are no Virtual Memory tuneables foreDirectory on Linux. The page cache in LinuxNovell eDirectory 8.7: Performance Tuning for Linux and UNIX12Untitled Documentkernel 2.4 gives excellent performance for databaseapplications in comparison with 2.2 kernels. The default TCP/IP settings on Linux givesatisfactory LDAP search performance and do notrequire further tuning.If you use the ext2 file system storing the DIB files for eDirectory, the file system should becreated with a block size of 4096 for optimumperformance. You can do this by the followingcommand before installing eDirectory:mke2fs -b 4096 device>You can also disable updating access times byrunning the following command for all the DIB files:chattr -A filename>The new reiserfs file system coming with the2.4.1 and above kernels has not been extensivelytested with eDirectory yet, so we cannot makeany recommendation at this point in time. As mentioned earlier, dynamic resizing of the eDirectory database cache does not inter-operate well with Linux internal caching and theglibc memory allocation algorithms. Therefore, we recommend that you always use a hard limitfor the cache to get optimal performance.Tuning AIX for eDirectoryNovell eDirectory 8.7 supports the AIX operatingenvironments of AIX 4.3 and AIX 5.1. The AIXplatform provides significant tools for optimizingperformance on the AIX platforms from VirtualMemory and Network I/O to Disk I/O. Note thatmajor changes occurred in the AIX environmentbetween the AIX 4.3 and AIX 5 releases and tuningoptions in AIX 4.3 and AIX 5.1 are changing in AIX 5.2.Tuning information for the various releases ofthe AIX operating environments are available atthe following Web sites:" AIX 4.3.http://publib.boulder.ibm.com/doc_link/en_US/a_doc_lib/aixbman/prftungd/toc.htm " AIX 5.1:http://publibn.boulder.ibm.com/doc_link/en_US/a_doc_lib/aixbman/prftungd/prftungdtfrm.htm " AIX 5.2:http://publib16.boulder.ibm.com/doc_link/en_US/a_doc_lib/aixbman/prftungd/prftungdtfrm.htm As mentioned earlier, we recommend using a minimum file system block size of 4096 bytes (or multiple thereof) which matches the defaultdatabase block size. Dynamic resizing of theeDirectory database cache does not interoperatewell with UNIX internal caching, therefore, we recommend you to always use a hard limit for the cache to get optimal performance.Novell eDirectory 8.7: Performance Tuning for Linux and UNIX13Untitled Document462-001358-003 2002, 2003 Novell, Inc. All rightsreserved. Novell, the Novell logo andConsoleOne are registered trademarks,and eDirectory and the N logo aretrademarks of Novell, Inc. in the United States and other countries.*UNIX is a registered trademark ofX/Open, Ltd. Linux is a registeredtrademark of Linus Torvalds. Red Hatis a registered trademark of Red Hat,Inc. Solaris and Sun are registeredtrademarks and JVM is a trademark of Sun Microsystems, Inc. AIX is aregistered trademark of InternationalBusiness Machines Corporation. RSAis a trademark of RSA Data Security,Inc. Veritas is a registered trademarkof Veritas Software Corporation. Allother third-party trademarks are theproperty of their respective owners.This product includes softwaredeveloped by the OpenSSL Project for use in the OpenSSL Toolkit(http://www.openssl.org).Novell Product Trainingand Support ServicesFor more information aboutNovell s worldwide producttraining, certification programs,consulting and technical supportservices, please visit:www.novell.com/ngageFor More InformationTo access the online documentationfor this and other Novell products,and to get updates, see:www.novell.com/documentationYou may also call Novell at:1 888 321 4272 US/Canada1 801 861 4272 Worldwide1 801 861 8473 FacsimileNovell, Inc.1800 South Novell PlaceProvo, Utah 84606 USA www.novell.comLegal NoticesNovell, Inc. makes no representations or warranties with respect to the contents or use of this documentation, and specifically disclaims any express orimplied warranties of merchantability or fitness for any particular purpose. Further, Novell, Inc. reserves the right to revise this publication and to makechanges to its content, at any time, without obligation to notify any person or entity of such revisions or changes.Further, Novell, Inc. makes no representations or warranties with respect to any software, and specifically disclaims any express or implied warranties ofmerchantability or fitness for any particular purpose. Further, Novell, Inc. reserves the right to make changes to any and all parts of Novell software, at anytime, without any obligation to notify any person or entity of such changes.You may not export or re-export this product in violation of any applicable laws or regulations including, without limitation, U.S. export regulations or thelaws of the country in which you reside.No part of this publication may be reproduced, photocopied, stored on a retrieval system, or transmitted without the express written consent of the publisher.U.S. Patent No. 5,608,903; 5,671,414; 5,677,851; 5,758,344; 5,784,560; 5,794,232; 5,818,936; 5,832,275; 5,832,483; 5,832,487; 5,870,739; 5,873,079;5,878,415; 5,884,304; 5,913,025; 5,919,257; 5,933,826. U.S and Foreign Patents Pending.
