MTU Directory Server ldap.mtu.edu Configuration
All settings here are based on information found in Sun ONE's Directory Server documentation. This documentation could be release notes, administration guides, etc. All references have been noted below.
| Parameter | Setting | Reason |
|---|---|---|
| sizelimit | 300 entries | No one should need to return 300 entries on a search. If they do, they may be doing something wrong or in an inefficient manner. Either way, the directory server administrator should be contacted to discuss the matter. |
| timelimit | 300 seconds | A timelimit of 5 minutes should be plenty of time to perform any operation that requires less than 100 entries (sizelimit). |
| idletimeout | 60 seconds | Sometimes clients "forget" to disconnect when they are done using the server. If they don't "remember" within 1 minute the server will disconnect them automatically to help save system resources. |
| lookthroughlimit | 100 entries | A search operation that requires the directory to look through more than 100 entries probably has inappropriate criteria in the search filter. |
| allidsthreshold | default (4000) | Information on how to use allidsthreshold to increase directory
server performance can be found in the Sun ONE Directory Server
Administrator's Guide. Based on this information we get: 4,000 / 0.005 = 800,000 4,000 / 0.05 = 80,000 4,000 / 0.50 = 8,000 So, an allidsthreshold of 4000 is good for a directory server that has between 8,000 and 800,000 entries, but is ideal for 80,000 entries. The MTU directory server has ~25,000 entries (rounded up). The ideal allidsthreshold for a directory server of this size would be: 25,000 * 0.05 = 1,250 However, setting it to this value doesn't leave much room to grow in size. Leaving it at 4,000 allows us to grow by 45,000 entries before the value should be changed. This is important because changing the allidsthreshold value requires all of the data in the directory server to be exported and then imported. Currently the allidsthreshold value is 1.6% of 25,000 which is perfectly acceptable. |
| dbcachesize | 2048 MB (2 GB) | Information on how to use dbcachesize to increase directory
server performance can be found in the Sun ONE Directory Server
Administrator's Guide. Based on this information we get: The machine ldap.mtu.edu is running on has a total of 4096 MB of system memory. Around 3800 MB of that was free at the time of this calculation. No other services are running on this machine, so we don't have to worry about leaving a lot of memory around. 3800 MB - cachesize - "safety space" cachesize = 256 MB "safety space" = 100 MB Final Calculation 3800 - 256 - 100 = 3444 MB However, we like multiples of 2 so we reduced this to 2048 MB (2 GB). We didn't use 3072 MB (3 GB) because the entire database with indices takes up less space than 2 GB so it doesn't need to be larger than 2 GB. |
| cachesize | 256 MB | Information on how to use cachesize to increase directory
server performance can be found in the Sun ONE Directory Server
Administrator's Guide. Based on this information we get: The cachesize parameter is measured in bytes to cache. The MTU directory server has approximately 25,000 entries in it, 17,000 of which will be accessed more frequently than others (person entries). Each entry is around 2 KB in size. Usually a search is executed once and rarely executed again so a large cachesize is unnecessary. We want to be able to cache at least 512 entries at any given time. Given that, the amount of available memory free, and the impact a large cachesize would have on the dbcachesize parameter, we get the following: cachesize = 512 entries * 2 KB per entry = 512 * 2 KB = 1 MB This seemed rather small to me so I gave it 256 MB because I had a lot left and the larger the cache the faster the performance. |
| db_idl_divisor | 4 | Given the size of our directory server setting this to 4 could be considered excessive. However, there is no reference stating that setting this slightly higher than usual will have any negative impact on performance. Real world tests indicate no performance degradation and it leaves us room to grow up to 1,000,000 entries before it would be necessary to change this. Changing this requires data to be exported and imported in order to manipulate write-block IDs. Avoiding an export/import sequence is almost always a good idea. |
References
Sun ONE Directory Server DocumentationPerformance Tuning Formulas
db_idl_divisor information - This site may no longer exist.
Home | MTU Information Technology | Michigan Technological University