With an entry cache and a block cache, the total available memory for caching is shared between the two caches. The default is an equal division (50% each). To maintain the amount of block cache available in versions of NDS prior to 8.73, you need to double the total cache size for eDirectory (because of the entry cache you now have). If you use the cache to boost LDIF-import performance, for example, you can either double the total cache size or change the default cache settings (as discussed later in this chapter).

The more blocks and entries that can be cached, the better the overall performance will be. The ideal configuration is to cache the entire database in both the entry and block caches. However, this is usually not possible especially when you have extremely large databases. Generally, the rule of thumb is to try to get as close to a 1:1 ratio of block cache to DIB set size as possible. For the entry cache, you should try to get close to a 1:2 or 1:4 ratio. For the best performance, you should exceed these ratios where possible.

eDirectory provides two methods for controlling cache memory consumption: a dynamically adjusting limit (Dynamic Adjust mode) and a hard memory limit (Hard Limit mode). The Hard Limit mode is the method that versions of eDirectory prior to 8.5 use to regulate memory consumption. You set a hard memory limit by specifying one of the following:

When a hard memory limit is specified in percentages, it is translated to a fixed number of bytes based on the amount of memory at the time the setting is made.

The Dynamic Adjust mode causes eDirectory to periodically adjust its memory consumption in response to the change in memory usage by other processes. You specify the limit as a percentage of available physical memory. Using this percentage, eDirectory recalculates a new memory limit at fixed intervals. The new memory limit will be the percentage of physical memory available at the time.

Along with this percentage, you can set maximum and minimum thresholds. Such a threshold is the number of bytes that eDirectory will adjust to. It can be set as either the number of bytes to use or the number of bytes to leave available. The minimum threshold default is 16MB, and the maximum threshold default is 4GB.

If the minimum and maximum threshold limits are not compatible with one another, the minimum threshold limit is followed. For example, suppose you specified the following settings:

When eDirectory adjusts its cache limit, there is 16MB of available physical memory. eDirectory calculates a new limit of 12MB (75% of 16MB). eDirectory then checks to see whether the new limit falls within the range of the minimum and maximum thresholds. In this example, the maximum threshold requires that 10MB remain available, so eDirectory lowers the limit to 6MB (leaving 10MB available). However, the minimum threshold is 8MB, so eDirectory resets the final limit to 8MB.

You can specify upper limits for the block cache and the entry cache separately. If no previously permanent cache settings are found when the DS agent (DSA) starts up, the cache defaults to a hard limit of 16MB for the first 10 minutes. Because the DSA usually loads when a server is restarted, this default behavior allows other applications to load and request system resources first. After 10 minutes, the behavior (by default) switches to Dynamic Adjust mode, based on the amount of available memory.

With the dynamically adjusting limit, you can also specify the interval length at which the memory limit is recalculated. The default interval is 15 seconds.

If the server does not have a replica, and no dynamic adjustments are specified, a hard memory limit of 16MB (with 8MB for the block cache and 8MB for the entry cache) is used. On the other hand, if the server contains one or more replicas, the default Dynamic Adjust mode uses a limit of 51% of available memory, with a minimum threshold of 8MB and a maximum threshold of keeping 24MB available to the operating system (that is, total available memory minus 24MB).

You can use either the Hard Limit mode or the Dynamic Adjust mode, but you can only use one at a time because the two are mutually exclusive. The last method selected will always replace any prior settings. As discussed in the following sections, there are three ways you can set the cache limits:

Setting Cache Usage via NDS iMonitor

An easier and more user-friendly, but not necessarily the fastest, method to configure cache settings is to use NDS iMonitor. The appropriate settings are made from the Database Cache Configuration page in NDS iMonitor (see Figure 16.1), which is accessed via the Database Cache link under Agent Configuration.

FIGURE 16.1 eDirectory database cache settings.

Periodically, you should check the eDirectory cache statistics to ensure that the settings used are effective. You can easily determine the various cache hits and misses (which are generally referred to as cache faults) by looking at the Database Cache statistics information from the Database Cache link under Agent Configuration in NDS iMonitor (see Figure 16.2).

FIGURE 16.2 eDirectory database cache information.

Of particular interest in the cache statistics is the percentage listed next to Requests Serviced from Cache. This number reflects the cache efficiency. The percentage is calculated as (Total Hits) / (Total Hits + Total Faults), where Total Hits is the total for both the block and entry caches. Typically you want to keep this number somewhere in the 90s for best cache efficiency. If this number is below 90%, you might want to look at how much available memory you have in your server and perhaps change the way your cache is allocated (for example, change the percentage of block cache versus entry cache).

By comparing the reported DIB size to the summed maximum size of entry cache and block cache, you can determine how much of the DIB can be cached. The example shown in Figure 16.2 suggests that all of the DIB can be cached because the DIB size is a little over 1MB in size (1,280KB), while the summed maximum cache size is almost 14MB. In this case, you could safely reduce the amount of maximum cache limit and free up the extra RAM for other server processes.

You manage eDirectory indexes by using ConsoleOne or iManager. Because these indexes are associated with the server, in ConsoleOne you access them through the Indexes tab on the Properties page of the NCP Server object. When using iManager, you select eDirectory Maintenance, Index Management, server. Figure 16.4 shows the Create Index dialog box from ConsoleOne. From the Indexes tab in ConsoleOne, you can also change an index’s state between Suspend and Online, delete a User Defined index, or copy an index definition to another server. At the time of this writing, you can use NDS iMonitor only to view the indexes and their states (by selecting Agent Summary, clicking the server name in the Navigator frame, and selecting indexDefinition from the list of attributes), as shown in Figure 16.5.

FIGURE 16.4 Adding an eDirectory index.

FIGURE 16.5 eDirectory index status.

Other than by using ConsoleOne and iManager, you can define and manage eDirectory indexes via LDAP. The advantage of using LDAP is that an application can define indexes during the installation process. Index definitions can be part of the same LDIF file that applies the required schema extension for the application. The LDIF file shown in Figure 16.6 creates a Substring index (called PhoneNumber substring) for the Telephone Number attribute.

FIGURE 16.6 An LDIF file to add a substring index.

You can also use LDAP to programmatically change the state of a defined index. You should first query the NCP Server object’s indexDefinition attribute to determine the current Index State value before modifying it. Then you set the Index State field to either 0 to suspend it or 2 to start bringing it online. You should never change the state to either Bringing Online (1) or Pending Creation (3). A background process does this automatically. The following LDIF commands change the state of the PhoneNumber substring index from Online to Suspended:

Although appropriate indexes can significantly improve performance, you should be aware of the cost associated with each index added to the directory. To start with, each addition, deletion, or modification of an entry in the directory causes all indexes affected by the change to be updated. Substring indexes are the most costly (that is, CPU intensive) to create and update, and Presence indexes are the least costly.

The more indexes that exist on a server, the longer the time it takes to perform add, delete, or modify operations. Consequently, indexes should be used judiciously. A secondary side-effect of adding indexes is that each index requires some storage to contain it. Thus, each index adds to the size of the server’s DIB.

So, which attributes should you index? To help make that determination, eDirectory provides the capability to capture search predicate statistics data. Predicate statistics data, often called predicate stats data, is a server-specific history of the objects people search for. You can use predicate stats to identify the most frequently searched for objects and then create indexes to improve the speed of future information access.

When eDirectory is installed, a special Predicate Stats object is created. The name of the object is the server name, with -PS appended (for example, NETWARE65-PS or WIN2K-NDS-PS). You can create as many objects of this type as you feel necessary, but typically a single object will suffice.

At the time of this writing, only ConsoleOne can be used to view and manage the predicate stats collected by an NCP Server object. Figure 16.7 shows an example of the ConsoleOne Predicate Data tab.

FIGURE 16.7 eDirectory predicate stats data.

The Predicate Stats object itself has no configuration option. All its settings are handled through the Predicate Data tab of the NCP Server object.

The following steps describe how to configure the Predicate Stats object and its functionality:

For testing purposes, you can shorten the refresh Update Interval setting and perform a few find operations by using ConsoleOne. This will generate some data to populate the Predicate Data tab display.

You can change the settings of the Predicate Stats object via its Other Edit tab instead of going through the NCP Server object’s Predicate Data tab.

In order to view the predicate statistics from ConsoleOne, the Write to Disk setting must be selected. Each time the internal table is flushed to the ndsPredicate attribute of the selected Predicate Stats object, the values in the table are compared to the predicates held by the object. If the values are the same, the count is simply updated to reflect the new instance of that predicate. If the internal table holds new predicates, they are added as values to the object.

If you decide to change the statistics display mode by toggling the Display Value Text check box, it is recommended that you first turn statistics collection off, clear out all the old statistics values, change the display mode setting, and then turn statistics collection back on.

Entries in the Predicate Data tab list are sorted by the number of times they have been used. The list may be a little difficult to read because it shows internal search information as well as user query information.

Figure 16.8 shows a number of entries that may be helpful in determining what attribute may warrant an index. The following three entries are examples of what to look for when deciding what indexes may be required:

FIGURE 16.8 The entry ID of the User class schema definition.

The first sample entry shows that the query used the filter NDS_CLASS_ID==437. This indicates that a search was performed on an object class whose (schema) entry ID value is 437 decimal (1B5 in hex). To find out what object class has an ID of 437, you need to use DSBrowse to perform a find based on the ID. Figure 16.8 shows that the User class schema definition has an entry ID of 1B5.

If you are seeing a high count value (meaning many searches using that filter) for NDS_CLASS_ID==437, you should check to see whether the same predicate search includes any attribute names, such as “search in all User objects whose Department attribute value is Sales.” If the answer is yes, the specified attribute names are potential candidates for indexing. Otherwise, creating an index for just the Object Class attribute may be useful; refer to the “General Guidelines for Using Indexes” section, later in this chapter, for more information.

The second predicate data entry example shows that the search was for a particular CN, an NCP Server object (dreamlan-w2k-nds). In more than 80% of the searches, specific object names (CN) are used. For example, “Show me all values in the ACL attribute for user Chelsea.” When you have many objects in the tree, indexing CN is an excellent idea—and that’s why CN is one of the predefined indexes. The other 20% of searches would include queries such as “Show me all the objects that have a Location value of New York City,” where the CN index is not used.

The third example shows that the filter NDS_PARENT_ID==32869 was used. This indicates that the search is either looking for a DS container (whose parent container’s entry ID is 32869 decimal or 0x8065 hexadecimal), objects in this container, or objects in this container and its subordinate containers. However, the parent ID here refers to the entry ID of the partition root object of the partition where the search is targeted. Using DSBrowse or NDS iMonitor, you can determine the name of the container based on the entry ID, thus the partition in question. Although this information does not help you to decide what attribute needs to be indexed, it does suggest whether you should put a replica of that partition on this server.

The following are a few points to keep in mind when working with predicate stats:

When the server receives a search request, the query is evaluated and broken into a combination of mini-terms. Each of these mini-terms (or tokens, as they are called in text string parsing parlance) becomes a search predicate. One index is selected as being optimal for each predicate. The indexed attribute is used to create the initial result pool for that predicate, and then the other predicate criteria are applied to form the final set. Result sets from the different predicates are then merged to form the final result set.

The complete rules for how an index is selected are complex and generally uninteresting to most people. The following are some simple guidelines to consider when working with eDirectory indexes:

Indexes are not miracle solutions to all query-based performance bottlenecks. They can greatly help improve search speeds if the applications can take advantage of them, such as by formulating and structuring the search filters to the way eDirectory works. But how can you find out after creating all the necessary indexes whether the still-not-so-speedy search response time is due to the applications or a system bottleneck somewhere else?

DSTrace provides much information to many eDirectory internal processes, and it can help you again in this situation. By setting the Record Manager filter for tracing, you can see which index was picked for a particular query.

The following example shows a ConsoleOne query that is looking for the x121Address attribute by doing a find for the attribute. Notice that the boldfaced message indicates that no index was used to perform the query:

The following example is a ConsoleOne query for a list of NCP Server objects in the tree. Notice that the highlighted message indicates that the ClassID_RDN_IX index, an internal eDirectory index, was used to perform the query:

Using the information provided by DSTrace along with the predicate stats provides you with some good tools for pinpointing possible bottlenecks in search performance.

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.

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:

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.

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.