Novell®
www.novell.com
Tuning Guide for UNIX* Platforms
novdocx (en) 22 June 2009
AUTHORIZED DOCUMENTATION
eDirectory
8.8 SP5
December 02, 2009
TM
Novell eDirectory Tuning Guide for UNIX* Platforms
Legal Notices
Novell, Inc. makes no representations or warranties with respect to the contents or use of this documentation, and
specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose.
Further, Novell, Inc. reserves the right to revise this publication and to make changes 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 of merchantability or fitness for any particular purpose. Further, Novell, Inc.
reserves the right to make changes to any and all parts of Novell software, at any time, without any obligation to
notify any person or entity of such changes.
Any products or technical information provided under this Agreement may be subject to U.S. export controls and the
trade laws of other countries. You agree to comply with all export control regulations and to obtain any required
licenses or classification to export, re-export, or import deliverables. You agree not to export or re-export to entities
on the current U.S. export exclusion lists or to any embargoed or terrorist countries as specified in the U.S. export
laws. You agree to not use deliverables for prohibited nuclear, missile, or chemical biological weaponry end uses.
Please refer to www.novell.com/info/exports/ for more information on exporting Novell software. Novell assumes no
responsibility for your failure to obtain any necessary export approvals.
Copyright © 2009 Novell, Inc. All rights reserved. No part of this publication may be reproduced, photocopied,
stored on a retrieval system, or transmitted without the express written consent of the publisher.
novdocx (en) 22 June 2009
Novell, Inc. has intellectual property rights relating to technology embodied in the product that is described in this
document. In particular, and without limitation, these intellectual property rights may include one or more of the U.S.
patents listed at http://www.novell.com/company/legal/patents/ and one or more additional patents or pending patent
applications in the U.S. and in other countries.
Novell, Inc.
404 Wyman Street, Suite 500
Waltham, MA 02451
U.S.A.
www.novell.com
Online Documentation: To access the online documentation for this and other Novell products, and to get
updates, see www.novell.com/documentation.
Novell Trademarks
Client32 is a trademark of Novell, Inc.
eDirectory is a trademark of Novell, Inc.
NetWare is a registered trademark of Novell, Inc., in the United States and other countries.
NetWare Core Protocol and NCP are trademarks of Novell, Inc.
NMAS is a trademark of Novell, Inc.
Novell is a registered trademark of Novell, Inc., in the United States and other countries.
Novell Client is a trademark of Novell, Inc.
Novell Directory Services and NDS are registered trademarks of Novell, Inc., in the United States and other
countries.
Ximian is a registerd trademark of Novell, Inc., in the United States and other countries.
ZENworks is a registered trademark of Novell, Inc., in the United States and other countries.
Third-Party Materials
All third-party trademarks are the property of their respective owners.
This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (http://
www.openssl.org).
novdocx (en) 22 June 2009
novdocx (en) 22 June 2009
4 Novell eDirectory Tuning Guide for UNIX* Platforms
About This Guide
novdocx (en) 22 June 2009
Welcome to Novell® eDirectoryTM 8.8. This guide describes how to analyze and tune Novell®
TM
eDirectory
on UNIX* platforms to yield superior performance in all deployments.
This guide introduces the following:
Chapter 1, “Overview,” on page 9
Chapter 2, “eDirectory Subsystems,” on page 11
Chapter 3, “Analyzing System Bottlenecks,” on page 15
Chapter 4, “Tuning eDirectory Subsystems,” on page 19
Chapter 5, “eDirectory Configuration,” on page 27
Audience
The guide is intended for network administrators.
Additional Documentation
For more information about eDirectory 8.8, refer to the following:
Novell eDirectory 8.8 Installation Guide
Novell eDirectory 8.8 Administration Guide
Novell eDirectory 8.8 What’s New Guide
Novell eDirectory 8.8 Troubleshooting Guide
These guides are available at Novell eDirectory 8.8 documentation Web site (http://
www.novell.com/documentation/edir88/index.html).
For information about the eDirectory management utility, see the Novell iManager 2.7
Administration Guide (http://www.novell.com/documentation/imanager27/index.html).
Documentation Conventions
In this documentation, a greater-than symbol (>) is used to separate actions within 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 platforms or a forward slash for
other platforms, the pathname is presented with a backslash. Users of platforms that require a
forward slash, such as Linux* and UNIX*, should use forward slashes as required by your software.
About This Guide 5
novdocx (en) 22 June 2009
6 Novell eDirectory Tuning Guide for UNIX* Platforms
Contents
About This Guide 5
1Overview 9
1.1 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2 eDirectory Subsystems 11
2.1 FLAIM Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.1 Checkpoint. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.2 Indexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.3 Roll-Forward Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2 Thread Pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3 Analyzing System Bottlenecks 15
novdocx (en) 22 June 2009
3.1 Disk I/O Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2 CPU Subsystem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3 Memory Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.4 Network Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4 Tuning eDirectory Subsystems 19
4.1 FLAIM Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1.1 Choosing Indexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.1.2 Tuning for Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2 Thread Pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.3 ACLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.3.1 Improving eDirectory Searches and Reads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.3.2 Disabling ACL Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.4 Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.5 SSL Overhead . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.6 64-Bit Versus 32-Bit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.7 Import Convert and Export (ICE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.8 ldif2dib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5 eDirectory Configuration 27
5.1 Configuring the FLAIM Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.1.1 Hard Cache Limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.1.2 Dynamically Adjusting the Limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2 Modifying FLAIM Cache Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2.1 Modifying FLAIM Cache Settings through iMonitor . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.2.2 Modifying FLAIM Cache Settings through _ndsdb.ini . . . . . . . . . . . . . . . . . . . . . . . . 29
Contents 7
novdocx (en) 22 June 2009
8 Novell eDirectory Tuning Guide for UNIX* Platforms
1
Overview
Novell® eDirectory 8.8TM is a standards-compliant, cross-platform, highly scalable, fault-tolerant,
and high-performance directory services solution. This guide provides information on tuning your
eDirectory environment for improved performance.
Tuning for performance is a complex activity. It requires understanding of both the eDirectory and
operating system's subsystems. It involves monitoring the system to identify bottlenecks and fixing
them one at a time. Many a times resources are limited and tuning is confined to eDirectory and the
operating system.
In this guide, read the Prerequisites section before attempting any kind of tuning, then proceed to the
other sections. eDirectory Subsystems chapter describes primary subsystems that influence
eDirectory performance. Analyzing System Bottlenecks chapter describes various system resources
and their influence on eDirectory performance. Tuning eDirectory Subsystems chapter describes
how to analyze and tune eDirectory under various conditions and environments. Finally, the
eDirectory Configuration chapter describes how to configure various tunable parameters.
novdocx (en) 22 June 2009
1
1.1 Prerequisites
Ensure that the following general prerequisites are met before attempting to tune the system for
performance:
A good eDirectory tree design (http://www.novell.com/documentation/edir88/edir88/data/
a2iiido.html) can enhance eDirectory performance. The following considerations might apply:
Applications read all the information locally on the server without needing to chain the
requests.
eDirectory efficiently handles object references automatically. If possible, objects on a
server should not refer to objects that are not local on that server, because maintaining
non-local object references can take more time. If such references exist, backlinks must be
maintained. This becomes cumbersome in large deployments.
If you need a group with 10,000 members or more, dynamic groups are recommended.
This allows you to avoid the overhead associated with maintaining references for so many
people. Choose your dynamic group configuration carefully, because using multiple
dynamic groups with improper search criteria might overload the server and reduce
overall server performance. If a search operation takes a long time to complete, the chosen
index might be inefficient. Minimize the use of regular(static) groups as this can increase
tree walking on login.
Use ACLs efficiently. For example, use the [This] trustee and assign it at the container
level instead of using an ACL template that assigns rights to itself. The fewer ACLs, the
better the performance. For more information on ACLs, refer to the Access Control List
(http://www.novell.com/documentation/edir88/edir88/data/fbachifb.html) in the Novell
eDirectory 8.8 Administration Guide.
Distribute the load onto multiple replica servers.
Overview
9
Although a good tree design minimizes the need for tree walking, it is still sometimes
necessary. Advanced Referral Costing (http://www.novell.com/documentation/edir88/
edir88/data/b9u7705.html) can be considered.
If logins are slow, you can disable login updates. There are separate ways to disable login
TM
updates for both NDS® and NMAS
logins. However, it is important to understand the
security implications (http://www.novell.com/documentation/nmas33/admin/
index.html?page=/documentation/nmas33/admin/data/bg8dphs.html).
Run health checks (http://www.novell.com/documentation/edir88/edir88/data/a5ziqam.html)
through iMonitor. Ensure the following:
Time is in sync across all replica servers.
Replica synchronization and background processes are in a healthy state.
novdocx (en) 22 June 2009
10 Novell eDirectory Tuning Guide for UNIX* Platforms
2
eDirectory Subsystems
This section discusses the eDirectory Subsystems.
Section 2.1, “FLAIM Database,” on page 11
Section 2.2, “Thread Pool,” on page 12
2.1 FLAIM Database
eDirectory uses FLAIM as its database. FLAIM (Flexible Adaptable Information Manager) is used
for traditional, volatile, and complex information. It is a very scalable database engine that supports
multiple readers and a single-writer concurrency model. Readers do not block writers and writers do
not block readers.
Physically, FLAIM organizes data in blocks. Some of the blocks are typically held in memory. They
represent the block cache. The entry cache (sometimes called a record cache) caches logical entries
from the database. Entries are constructed from the items in the block cache. FLAIM maintains hash
tables for both caches. The hash bucket size is periodically adjusted based on the number of items.
novdocx (en) 22 June 2009
2
By default eDirectory uses a block size of 4 KB. The block cache size for caching the complete DIB
is equal to the DIB size, and the size required for the entry cache is about two to four times the DIB
size.
While retrieving an entry, FLAIM first checks for the entry in the entry cache. If the entry exists,
reading from the block cache isn't necessary. While retrieving a block from the disk, FLAIM first
checks for the block in the cache. If the block exists, a disk read operation isn't necessary.
When an entry is added or modified, the corresponding blocks for that entry are not directly
committed to the disk, so the disk and memory might not be in sync; however, the updates made to
the entry are logged to the roll-forward log (RFL). An RFL is used to recover transactions after a
system failure.
Least Recently Used (LRU) is the replacement algorithm used for replacing items in the cache.
Section 2.1.1, “Checkpoint,” on page 11
Section 2.1.2, “Indexes,” on page 12
Section 2.1.3, “Roll-Forward Log,” on page 12
2.1.1 Checkpoint
A checkpoint brings the on-disk version of the database to the same coherent state as the in-memory
(cached) database. FLAIM can perform a checkpoint during the minimal update activity on the
database. It runs every second and writes the dirty blocks (dirty cache) to the disk. Blocks that are
modified in the cache but not yet written to the disk are called “dirty blocks”. FLAIM acquires a
lock on the database and performs the maximum amount of possible work until either the checkpoint
eDirectory Subsystems
11
completes or another thread is waiting to update the database. To prevent the on-disk database from
becoming too far out of sync, there are conditions under which a checkpoint is forced even if threads
are waiting to update the database:
If the checkpoint thread cannot complete a checkpoint within a specified time interval (the
default is 3 minutes), it is forced and the dirty cache is cleaned.
If the size of the dirty cache is larger than the maxdirtycache (if set), a checkpoint is forced to
bring down the dirtycache size to mindirtycache (if set) or to zero.
2.1.2 Indexes
An index is a set of keys arranged in a way that significantly speeds up the task of finding any
particular key within the index. Index keys are constructed by extracting the contents of one or more
fields (attributes) from the entries. Indexes are maintained in the block cache. Any changes to the
indexed attributes requires changes in the index blocks.
eDirectory defines a default set of indexes for system attributes (fields). System attributes such as
parentID and ancestorID are used for one-level and subtree searches. These indexes cannot be
suspended or deleted. The directory internally uses them. Default indexes are defined for attributes
such as CN, Surname, Given Name, and so on. Indexes can be of type presence, value, and substring
indexes. These indexes can be suspended. On deletion they are automatically re-created.
novdocx (en) 22 June 2009
You can use iManager or the ndsindex LDAP utility to create indexes. Indexes (http://
www.novell.com/documentation/edir88/edir88/data/a5tuuu5.html) are server-specific.
By enabling the RECM tag in the ndstrace, you can view the index chosen for the search queries.
The following example is for an ndstrace log for a subtree search using
3019918240 RECM: Iter #b239c18 query ((Flags&1)==1) &&
((CN$217A$.Flags&8=="admin") && (AncestorID==32821))
3019918240 RECM: Iter #b239c18 index = CN$IX$220
The following example is for an ndstrace log for a subtree search using
for testing”
2902035360 RECM: Iter #83075b0 query ((Flags&1)==1) &&
((Description$225A$.Flags&8=="This is for testing") && (AncestorID==32821))
2902035360 RECM: Iter #83075b0 index = AncestorID_IX
, AncestorID.
“cn=admin”
“Description= This is
, CN.
2.1.3 Roll-Forward Log
FLAIM logs operations for each update transaction in a roll-forward log (RFL) file. An RFL is used
to recover transactions from a system failure or when restoring from a backup. The RFL file is
truncated after every checkpoint is completed unless it is turned on (rflkeepfiles) by using a hot
continuous backup (http://www.novell.com/documentation/edir88/edir88/data/a2n4mb7.html).
2.2 Thread Pool
eDirectory is multi-threaded for performance reasons. In multi-threading, when the system is busy,
more threads are created to handle the load and some threads are terminated to avoid extra overhead.
It is inefficient and costly to frequently create and destroy threads. Instead of spawning new threads
12 Novell eDirectory Tuning Guide for UNIX* Platforms
and destroying them for every task, a number of threads are started and placed in a pool. The system
allocates the threads from the thread pool to several tasks as needed. Tasks are held in two types of
queues:
Tasks that need immediate scheduling are held in the Ready queue.
Tasks that need scheduling at a later time are held in the Waiting queue.
Not every module uses the thread pool. The actual number of threads for the process is more than
the number that exists in the thread pool. For example, FLAIM manages its background threads
separately.
novdocx (en) 22 June 2009
Running the
The total number of threads that are spawned, terminated, and idle.
The total number of worker threads currently and the peak number of worker threads.
The number of tasks and peak number of tasks in the Ready queue.
The minimum, maximum and average number of microseconds spent in the Ready queue.
The current and maximum number of tasks in the Waiting queue.
ndstrace -c threads
command returns the following thread pool statistics:
An example of a sample thread pool:
There are certain thread pool parameters:
n4u.server.max-threads: Maximum number of threads that can be available in the pool.
n4u.server.idle-threads: Maximum number of idle threads that can be available in the pool.
n4u.server.start-threads: Number of threads started.
Run the
ndsconfig get
and
ndsconfig set
commands to get and set the thread pool size.
eDirectory Subsystems 13
novdocx (en) 22 June 2009
14 Novell eDirectory Tuning Guide for UNIX* Platforms
3
Analyzing System Bottlenecks
There are several system resources that influence eDirectory performance. In addition, upgrading to
the latest version of operating system improves performance.
Section 3.1, “Disk I/O Subsystem,” on page 15
Section 3.2, “CPU Subsystem,” on page 16
Section 3.3, “Memory Subsystem,” on page 16
Section 3.4, “Network Subsystem,” on page 17
3.1 Disk I/O Subsystem
The disk subsystem is the most common bottleneck. The I/O takes a relatively long time with longer
queues, resulting in high disk utilization and idle CPU cycles. Use the iostat tool during expected
peak loads to determine the average response time indicators.
novdocx (en) 22 June 2009
3
Disk read, write, and update operations can be sequential or random. Random reads and updates is
the most common access pattern in eDirectory deployments.
Some solutions for random workloads:
Increase the RAM. This allows caching frequently used data or read-ahead data at the
filesystem layer. It also allows caching the DIB within the FLAIM subsystem.
Use dedicated volumes for the DIB. Filesystem performance improves for volumes created
closer to the spindle. Use dedicated volumes for RFL and other logs.
As disks develop increasing latency over a period of time because of fragmentation, they
should be defragmented.
Add separate disk drives for FLAIM RFL. This type of logging can be performed on high-
speed disks.
Use a RAID 10(1+0) environment with more disk drives.
Files created by eDirectory can grow to 4 GB. Filesystems that are optimized to handle large files
work efficiently with eDirectory.
For Solaris
metadata is optimized for large files. The UFS filesystem is indirectly block-based, where the
filesystem metadata is stored in larger number of blocks. It can even be scattered for large files,
which makes UFS slower for larger files.
For Linux
ext3 filesystem on large DIB sets. However, the write back journaling mode of ext3 is known to
match the performance of the Reiser filesystem although the default ordered mode provides
better data consistency. XFS is a high-performance journaling file system, capable of handling
large files and offering smooth data transfers. eDirectory 8.8 SP5 is supported on SLES 11 32
and 64-bit platforms having XFS file system.
TM
, the Veritas* VxFS filesystem is an extent-based file system where the file system
TM
, the Reiser filesystem is a fast journaling file system and performs better than the
FLAIM supports a block size of 4 KB and 8 KB. By default, it is 4 KB. This is same as the default
block size on Linux (tune2fs -l device). However, on Solaris, the UFS filesystem is created with a
default block size of 8 KB(df -g mountpoint). If the FLAIM block size is smaller than the filesystem
Analyzing System Bottlenecks
15
block size, partial block writes can happen. If the database block size is larger than the filesystem
block size, individual block reads and writes are split into a series of distinct physical I/O operations.
Therefore, you should always keep the FLAIM block size the same as the filesystem block size.
Block sizes can be controlled only during the creation of the DIB. Add a line “blocksize=8192” to
_ndsdb.ini
Choosing the right block size depends on the average size of the FLAIM record on your
deployments. Empirical testing is required on the right set of test data to determine which block size
is better for your deployment.
to create the DIB with 8K block size.
3.2 CPU Subsystem
eDirectory is built on a highly scalable architecture. The performance increases with the increase in
the number of processors. Increased throughput is observed until at least the 12th processor under
heavy load; however, this increase is subject to the performance of other resources during the
increasing load on the system. Servers are often under-configured with disks and memory. You
should add more processors only under the following circumstances:
If the average load on currently used processors is beyond 75% percent utilization. If the
current CPU utilization is below 75%, adding more CPUs might not improve performance.
If there is a satisfying increase in performance.
novdocx (en) 22 June 2009
If eDirectory is configured with too many threads, considerable amount of CPU time is spent in
context switching. In this case, a decrease in threads can result in better throughput.
3.3 Memory Subsystem
Server applications can perform significantly better when RAM is increased. Caching the eDirectory
database in the filesystem or in the FLAIM cache can lead to improved performances of search and
modify operations. However, you cannot cache the complete DIB in large deployments. Avoid page
swapping even if it means reducing the FLAIM entry and block cache sizes. Use the vmstat tool to
find more information on the memory subsystem.
As eDirectory uses memory, each thread from the thread pool uses 1 MB of RAM for its stack. By
default, the FLAIM cache size is set to 200 MB.
Several loadable modules are started when eDirectory starts, but the loadable module architecture of
eDirectory allows you to reduce the memory footprint of the process by not loading the unused
modules (for example, SecretStore, LDAP, or eMBox). In addition, products like IDM have some
modules that run inside eDirectory.
The memory used by eDirectory might appear to be growing. Although memory is freed by an
eDirectory process, it might not be released to the system free pool because the memory manager
used internally by eDirectory tries to optimize the memory allocations for future. This is one of the
reasons for not recommending FLAIM dynamic configuration. Use the Top tool to find the
approximate virtual memory size of the ndsd process in your deployment.
The maximum memory that can be allocated to a process is limited in several ways. A certain
amount of RAM is used by the operating system and other processes on the system. The operating
system can impose limitations on physical RAM that a process uses. For example, a 32-bit
16 Novell eDirectory Tuning Guide for UNIX* Platforms
eDirectory limits the FLAIM cache to 2.5 GB, but with 64-bit eDirectory, FLAIM caches can grow
beyond 2.5 GB. However, the 64-bit eDirectory needs an increased memory footprint
(approximately 20%) than the 32-bit eDirectory.
3.4 Network Subsystem
Typical deployments have sufficient bandwidth to handle peak network load. Adequate bandwidth
reduces errors, collisions, and dropped packets. Use the netstat tool to determine the network
statistics.
Several operating systems provide TCP/IP tunable parameters for tuning network intensive servers.
For information, refer to the documentation for the operating systems.
If the network is the bottleneck, you should increase the bandwidth. Configuring a dedicated private
network between the application servers and the eDirectory server might also help in reducing the
network congestion.
novdocx (en) 22 June 2009
Analyzing System Bottlenecks 17
novdocx (en) 22 June 2009
18 Novell eDirectory Tuning Guide for UNIX* Platforms
4
Tuning eDirectory Subsystems
This section includes the following information:
Section 4.1, “FLAIM Database,” on page 19
Section 4.2, “Thread Pool,” on page 20
Section 4.3, “ACLs,” on page 21
Section 4.4, “Replication,” on page 23
Section 4.5, “SSL Overhead,” on page 24
Section 4.6, “64-Bit Versus 32-Bit,” on page 24
Section 4.7, “Import Convert and Export (ICE),” on page 25
Section 4.8, “ldif2dib,” on page 25
4.1 FLAIM Database
novdocx (en) 22 June 2009
4
Cache sizing is arguably the most important factor affecting the overall performance of eDirectory.
The greater the number of items (blocks and entries) that can be cached, the better the overall
performance is. The percentage of times that the blocks or entries are found in the cache is called the
hit ratio. A higher ratio results in better performance. iMonitor can be used to view the hit ratio.
The block cache is most useful for update operations. The entry cache is most useful for operations
that performs a base-scoped search for an entry. However, both one-level and sub-tree scoped
searches use the entry cache as well as the block cache. The block cache is used to retrieve indexes.
Create the right type of indexes as necessary, for more information see “Choosing Indexes” on
page 20.
A fault in the block cache can result in a disk read operation. Disk reads are always expensive, but
they can be avoided if a block is retrieved from the filesystem cache.
The amount of memory required to cache the complete database in the block cache is nearly the size
of the database on the disk, and the amount of memory required to cache the complete database in
the entry cache is nearly two to four times the database size on the disk. When you have less
memory on a system, try a smaller entry cache and a much larger block or filesystem cache.
If reads are localized to a set of entries in the directory, you should increase the entry cache as long
as it results in an improved entry cache hit ratio.
If the read pattern is completely random and the DIB is much larger than the available RAM, you
should have a larger block cache or a filesystem cache than the entry cache.
Any method you use to tune eDirectory for an improved performance needs empirical testing. A
good ratio of entry to block cache for search-intensive environments is 2:1 ratio. Ensure that
sufficient memory is left for other processes. Avoid page swapping even if it means reducing the
FLAIM cache sizes.
Because FLAIM provides preallocated caching, memory allocated to the eDirectory cache is never
fragmented by the native operating system memory manager.
Tuning eDirectory Subsystems
19
4.1.1 Choosing Indexes
Indexes are meant to improve the one-level or sub-tree scoped search performance. Dynamic
groups also use one-level or sub-tree scoped searches. Indexes are not used for base-scoped
searches.
Because a Presence index does not differentiate between present and not present (deleted) values, it
is mainly used for internal purpose. If applications run a Presence type search query, this index is
never used, so applications should not have Presence indexes created for them.
Applications can create a Value index for an attribute, which is sufficient for most of the searches.
FLAIM can use a Value index for performing both Presence as well as Substring searches on the
attributes.
A Substring index can significantly decelerate the updates performed on an attribute. The number of
index blocks required to support a Substring index is quite large compared to the Value index. This
means more block cache is required to cache them. Create a Substring index only when necessary. A
Value index should suffice for most searches. However, if Substring searches do not yield acceptable
performance with a Value index, you can create a Substring index on those attributes.
novdocx (en) 22 June 2009
If a search operation takes a long time to complete despite the chosen index, you might introduce a
newer value index on one of the attributes of the search filter. Pick the attribute that yields best
results when indexed.
4.1.2 Tuning for Updates
The block cache is most useful for update operations. Indexes also reside in the block cache.
Although indexes help in faster searches, having too many indexes keeps the server busy
maintaining them. Indexes are modified if attribute values are modified, added, or deleted. During
large upload operations, indexes can be disabled for faster upload.
Having the RFL directory on a different disk than the DIB directory improves performance.
An acceptable limit for response time for an update operation can be controlled by using the
maxdirtycache. For example, if an acceptable limit for the server response is 5 seconds and random
disk write speed is 20 MB per second, then the maxdirtycache should be set as 20x5 = 100 MB.
Ensure that the block cache can hold these dirty blocks in memory. See Section 5.2.2, “Modifying
FLAIM Cache Settings through _ndsdb.ini,” on page 29 for more information.
4.2 Thread Pool
By default, the maximum number of threads that can be available in the thread pool is 128. This
number should suffice for most deployments. It can be increased to 512 threads in larger
deployments. You should increase the number of threads in the pool in the following cases:
If the number of idle threads is often zero.
If the average amount of time spent by a task in the Ready queue is high and increasing.
If the number of tasks in the Ready queue is high and increasing.
Keep increasing the max threads if the performance of the server increases. It should also result in
increased CPU utilization.
20 Novell eDirectory Tuning Guide for UNIX* Platforms
4.3 ACLs
Section 4.3.1, “Improving eDirectory Searches and Reads,” on page 21
Section 4.3.2, “Disabling ACL Templates,” on page 22
4.3.1 Improving eDirectory Searches and Reads
An LDAP search in eDirectory returns results depending on the number of attributes returned for a
user (inetOrgPerson).
When an object is created in eDirectory, default ACLs might be added on the object. This depends
on ACL templates in the schema definition for the objectClass to which this object belongs. For
example, in the default configuration for inetOrgPerson, there can be up to six ACLs added on the
user object. When an LDAP search request is made to return this user object with all attributes, it
takes slightly longer to return this object to the client than returning this user object without ACL
attributes.
Though default ACLs can be turned off, administrators may not want to turn them off because they
are required for better access control. However, you can improve the search performance by not
requesting them or by marking them as read filtered attributes. These changes do not break any
applications because most applications use effective privileges and do not rely on specific ACLs.
novdocx (en) 22 June 2009
Not requesting ACLs: An ACL attribute is not needed by several applications, so the applications
can be modified to request specific attributes in which the application is interested. This results in
better performance of the LDAP search.
Marking an ACL as read filtered: If an application cannot be modified, the arf_acl.ldif can be
used by an administrator to mark the ACL attribute as a read filtered attribute. When the ACL is
marked as a read filtered attribute, the server does not return the attribute on the entry if all attributes
are requested. However, the if the LDAP search is done to return operational attributes or if the
request specifically asks for ACL attributes, the marked attribute is returned. rrf_acl.ldif can be used
to turn off the read filtered flag on an ACL attribute. These LDIFs affect the ACL attribute on the
schema, so only a user with Supervisor rights on tree root can extend them.
By default, an ACL is not marked as read filtered, so the performance benefit for requests to return
all attributes is not seen.
The following table depicts the location of arf_acl.ldif and rrf_acl.ldif files in different platforms.
Platform Location
UNIX
NetWare
Windows
/opt/novell/eDirectory/lib/nds-schema/
<unzipped_location>\nw\sys\system\schema
<unzipped_location>\nt\I386\NDSonNT\ndsnt\nds
Tuning eDirectory Subsystems 21
4.3.2 Disabling ACL Templates
You can disable the Access Control List (ACL) templates to increase the bulkload performance. The
implication of this is that some of the ACLs will be missing; however, you can resolve this by
adding the required ACLs to the LDIF file or applying them later.
1 Run the following command:
ldapsearch -D cn_of_admin -w password -b cn=schema -s base
objectclasses=inetorgperson
The output of this command would be as follows:
dn: cn=schema
objectClasses: (2.16.840.1.113730.3.2.2 NAME ’inetOrgPerson’ SUP
organizationalPerson STRUCTURAL MAY (groupMembership $ ndsHomeDirectory
$ loginAllowedTimeMap $ loginDisabled $ loginExpirationTime $
loginGraceLimit $ loginGraceRemaining $ loginIntruderAddress $
loginIntruderAttempts $ loginIntruderResetTime $
loginMaximumSimultaneous $ loginScript $ loginTime $
networkAddressRestriction $ networkAddress $ passwordsUsed $
passwordAllowChange $ passwordExpirationInterval $
passwordExpirationTime $ passwordMinimumLength $ passwordRequired $
passwordUniqueRequired $ printJobConfiguration $ privateKey $ Profile $
publicKey $ securityEquals $ accountBalance $ allowUnlimitedCredit $
minimumAccountBalance $ messageServer $ Language $ UID $
lockedByIntruder $ serverHolds $ lastLoginTime $ typeCreatorMap $
higherPrivileges $ printerControl $ securityFlags $ profileMembership $
Timezone $ sASServiceDN $ sASSecretStore $ sASSecretStoreKey $
sASSecretStoreData $ sASPKIStoreKeys $ userCertificate
$ nDSPKIUserCertificateInfo $ nDSPKIKeystore $ rADIUSActiveConnections $
rADIUSAttributeLists $ rADIUSConcurrentLimit $ rADIUSConnectionHistory
$ rADIUSDefaultProfile $ rADIUSDialAccessGroup $ rADIUSEnableDialAccess
$ rADIUSPassword $ rADIUSServiceList $ audio $ businessCategory $
carLicense $ departmentNumber $ employeeNumber $ employeeType $
givenName $ homePhone $ homePostalAddress $ initials $ jpegPhoto $
labeledUri $ mail $ manager $ mobile $ pager $ ldapPhoto $
preferredLanguage $ roomNumber $ secretary $ uid $ userSMIMECertificate
$ x500UniqueIdentifier $ displayName $ userPKCS12) X-NDS_NAME ’User’ X
-NDS_NOT_CONTAINER ’1’ X-NDS_NONREMOVABLE ’1’ X-NDS_ACL_TEMPLATES
(’2#subtree#[Self]#[All Attributes Rights]’ ’6#entry#[Self]#loginScript’
’1#subtree#[Root Template]#[Entry Rights]’
’2#entry#[Public]#messageServer’ ’2#entry#[Root Template]#groupMembership’
’6#entry#[Self]#printJobConfiguration’ ’2#entry#[Root
Template]#networkAddress’))
2 In the output noted in the previous step, delete the information marked in bold.
3 Save the revised output as an LDIF file.
4 Add the following information to the newly saved LDIF file:
dn: cn=schema
changetype: modify
delete: objectclasses
objectclasses: (2.16.840.1.113730.3.2.2)
-
add:objectclasses
novdocx (en) 22 June 2009
22 Novell eDirectory Tuning Guide for UNIX* Platforms
Therefore, your LDIF should now be similar to the following:
dn: cn=schema
changetype: modify
delete: objectclasses
objectclasses: (2.16.840.1.113730.3.2.2)
-
add:objectclasses
objectClasses: (2.16.840.1.113730.3.2.2 NAME ’inetOrgPerson’ SUP
organizationalPerson STRUCTURAL MAY (groupMembership $ ndsHomeDirectory
$ loginAllowedTimeMap $ loginDisabled $ loginExpirationTime $
loginGraceLimit $ loginGraceRemaining $ loginIntruderAddress $
loginIntruderAttempts $ loginIntruderResetTime $
loginMaximumSimultaneous $ loginScript $ loginTime $
networkAddressRestriction $ networkAddress $ passwordsUsed $
passwordAllowChange $ passwordExpirationInterval $
passwordExpirationTime $ passwordMinimumLength $ passwordRequired
$ passwordUniqueRequired $ printJobConfiguration $ privateKey $ Profile $
publicKey $ securityEquals $ accountBalance $ allowUnlimitedCredit $
minimumAccountBalance $ messageServer $ Language $ UID $
lockedByIntruder $ serverHolds $ lastLoginTime $ typeCreatorMap $
higherPrivileges $ printerControl $ securityFlags $ profileMembership $
Timezone $ sASServiceDN $ sASSecretStore $ sASSecretStoreKey $
sASSecretStoreData $ sASPKIStoreKeys $ userCertificate $
nDSPKIUserCertificateInfo $ nDSPKIKeystore $ rADIUSActiveConnections $
rADIUSAttributeLists $ rADIUSConcurrentLimit $ rADIUSConnectionHistory $
rADIUSDefaultProfile $ rADIUSDialAccessGroup $ rADIUSEnableDialAccess
$ rADIUSPassword $ rADIUSServiceList $ audio $ businessCategory $
carLicense $ departmentNumber $ employeeNumber $ employeeType $ givenName
$ homePhone $ homePostalAddress $ initials $ jpegPhoto $ labeledUri $ mail
$ manager $ mobile $ pager $ ldapPhoto $ preferredLanguage $ roomNumber
$ secretary $ uid $ userSMIMECertificate $ x500UniqueIdentifier $
displayName $ userPKCS12) X-NDS_NAME ’User’ X-ND S_NOT_CONTAINER ’1’ X
-NDS_NONREMOVABLE ’1’)
5 Enter the following command:
ldapmodify -D cn_of_admin -w password -f LDIF_file_name
novdocx (en) 22 June 2009
4.4 Replication
When a new server is added to a tree, it is synchronized with its replica. This synchronization can
take considerable time, depending on the size of the partition. Synchronization can be avoided by
using DIBClone (http://www.novell.com/documentation/edir88/edir88/data/acavuil.html#aky13ak),
which allows cloning a server with the same partitions.
By default, in eDirectory, the maximum number of synchronization threads is set to 8. The
maximum allowed value is 16. This value can be increased if a large number of partitions are held
by the server or when a large number of replica servers exist for the partitions held by the server.
Go to the Agent Configuration in the iMonitor, then click Agent Synchronization from the left pane
to view or change the replication settings.
Tuning eDirectory Subsystems 23
Figure 4-1 Agent Synchronization
novdocx (en) 22 June 2009
A dynamically adjusted configuration uses “by server” synchronization if the number of replica
servers of all partitions held by the server is more than the number of partitions held by the server.
Otherwise it uses the “by partition” synchronization method.
The number of threads used by the “by server” synchronization method is half the number of
servers.
The number of threads used by the “by partition” synchronization method is same as the
number of partitions.
For example, if the synchronization thread count is set to 16 and if there are 18 servers, 9 threads are
used for the “by server” synchronization method.
4.5 SSL Overhead
LDAP over SSL adds an additional load on the CPU because of its encryption requirements. A lab
performance study shows greater than a 10% performance hit because of encryption overhead.
4.6 64-Bit Versus 32-Bit
Because of the increased size of some of the basic data types in 64-bit eDirectory environments, it
needs an increased memory (approximately 20%) over the same instance of 32-bit eDirectory.
24 Novell eDirectory Tuning Guide for UNIX* Platforms
eDirectory running as a 32-bit application can only allocate 4 GB memory to the process which
limits the amount of usable cache. The maximum size of the FLAIM cache in a 32-bit eDirectory
instance is limited to 2.5 GB. This is not a limitation with 64-bit eDirectory, where process memory
can grow beyond 4 GB.
The most significant setting that affects eDirectory performance is the cache. Therefore, 64-bit
eDirectory performs better for DIBs larger than 1 GB. It is observed through tests that increasing the
hit ratio on larger DIB by increasing the cache results in better performance.
When 32-bit eDirectory runs on a 64-bit operating system, a larger filesystem cache can result in a
higher throughput even though the FLAIM cache is limited to 2.5 GB. The operating system
automatically uses the available RAM for a filesystem cache.
64-bit eDirectory on a Linux x86_64 bit system performs better than the 32-bit eDirectory.
64-bit eDirectory on Solaris sparcv9 systems did not show significant difference in performance in
comparison with the same 32-bit instance of eDirectory. With larger DIB sets, it shows increased
performance due to a bigger FLAIM cache.
4.7 Import Convert and Export (ICE)
novdocx (en) 22 June 2009
The Novell Import Convert and Export (ICE) utility uses an optimized bulk update protocol called
LBURP to upload data into eDirectory. This protocol is significantly faster than uploading data by
using a simple
Performance (http://www.novell.com/documentation/edir88/edir88/data/bqu6wcq.html) in the
Novell eDirectory 8.8 Administration Guide.
ldapmodify
command. For more information, refer to the Improving Bulkload
4.8 ldif2dib
For tuning eDirectory performance during offline bulk upload by using the ldif2dib utility, refer to
the Tuning ldif2dib (http://www.novell.com/documentation/edir88/edir88/data/b4f3qw0.html) in the
Novell eDirectory 8.8 Administration Guide.
Tuning eDirectory Subsystems 25
novdocx (en) 22 June 2009
26 Novell eDirectory Tuning Guide for UNIX* Platforms
5
eDirectory Configuration
This section includes the following information:
Section 5.1, “Configuring the FLAIM Subsystem,” on page 27
Section 5.2, “Modifying FLAIM Cache Settings,” on page 27
5.1 Configuring the FLAIM Subsystem
In order to address a wide range of deployments and configurations, two mechanisms for controlling
the cache memory consumption are provided in the eDirectory. These mechanisms are mutually
exclusive.
Section 5.1.1, “Hard Cache Limit,” on page 27
Section 5.1.2, “Dynamically Adjusting the Limit,” on page 27
novdocx (en) 22 June 2009
5
5.1.1 Hard Cache Limit
You can specify a hard memory limit in one of the following ways:
As a fixed number of bytes.
As a percentage of physical memory.
As a percentage of available physical memory.
When a hard limit is specified by using the second or third method, it is always translated to a fixed
number of bytes. This means that for the second method, the number of bytes is the percentage of
physical memory detected when eDirectory is started. For the third method, the number of bytes is
the percentage of available physical memory detected when eDirectory is started.
5.1.2 Dynamically Adjusting the Limit
A dynamic adjustment causes eDirectory to periodically adjust its memory consumption in response
to the variable memory consumption by other processes. Although adjusting memory dynamically
works well in typical scenarios, this mechanism is not recommended for optimal performance of
eDirectory on UNIX platforms because of large differences in memory usage patterns and memory
allocators on UNIX platforms.
5.2 Modifying FLAIM Cache Settings
Section 5.2.1, “Modifying FLAIM Cache Settings through iMonitor,” on page 28
Section 5.2.2, “Modifying FLAIM Cache Settings through _ndsdb.ini,” on page 29
eDirectory Configuration
27
5.2.1 Modifying FLAIM Cache Settings through iMonitor
You can use iMonitor to do the following:
View or change the cache settings.
novdocx (en) 22 June 2009
Monitor the cache statistics.
Refer to the Database cache under Agent Configuration of iMonitor for the above information.
28 Novell eDirectory Tuning Guide for UNIX* Platforms
Database Cache Information Description
Maximum Size The maximum size (in KB) that the specified cache is allowed to grow
to.
Current Size The current size (in KB) of the specified cache.
Items Cached The number of items in the specified cache.
Old Versions Cached The number of old versions in the specified cache. Old versions of
cache items are kept to maintain the consistency of read transactions
in the database. In other words, if one thread is in a read transaction
and another is in a write transaction, old versions of blocks modified
by the writer are maintained on behalf of the reader. This is done so
that the reader’s results are guaranteed to produce a consistent view
during the life of its transaction even though modifications are taking
place during that time.
Old Versions Size The size (in KB) of the old version items cached.
Hits The number of times an item was successfully accessed from the
specified cache.
novdocx (en) 22 June 2009
Hit Looks The number of items looked at in the cache before an item was
successfully accessed from the specified cache. The hit-look-to-hit
ratio is a measure of cache lookup efficiency. Normally, the ratio
should be close to 1:1.
Faults The number of times an item was not found in the specified cache
and had to be obtained in a lower level cache or from the disk.
Fault Looks The number of items looked at in the cache before it was determined
that the desired item was not in the specified cache. The fault-lookto-fault ratio is a measure of cache lookup efficiency. Normally, the
ratio should be close to 1:1.
5.2.2 Modifying FLAIM Cache Settings through _ndsdb.ini
The FLAIM cache settings and other FLAIM configurations can be performed by modifying the
_ndsdb.ini
changed.
You can set the dynamically adjusting limit or the hard cache limit. The cache options are listed
below. Multiple options can be specified, in any order, separated by commas. All are optional.
DYN or HARD - Dynamically adjusting a limit or hard limit.
% : percentage - Percentage of available or physical memory to use.
AVA I L o r T OTA L - The percentage specifies available memory or total physical memory. It
is applicable only for the hard limit and ignored for the dynamically adjusting limit, because
dynamically adjusting limits are always calculated based on the available physical memory. By
default, it is AVAIL.
MIN: bytes - Minimum number of bytes.
MAX: bytes - Maximum number of bytes.
file that resides in the DIB directory. Restart eDirectory when
_ndsdb.ini
file is
LEAVE: bytes - Minimum number of bytes to leave.
eDirectory Configuration 29
For example:
cache=HARD,%:75, MIN:200000000
cache=500000000
preallocatecache: true/false - This setting causes eDirectory to preallocate the amount of
memory specified by the hard cache limit.
rfldirectory - A different path can be specified for RFL files.
cpinterval - Number of seconds after which FLAIM forces a checkpoint. The default is 3
minutes.
maxdirtycache - Maximum dirty cache bytes.
lowdirtycache - Minimum dirty cache bytes.
blockcachepercent - Percentage of the FLAIM cache used for block cache.
cacheadjustinterval - Interval in seconds for dynamically adjusting the cache.
cachecleanupinterval - Interval in seconds for cleaning up older versions of entries and blocks
from the cache.
novdocx (en) 22 June 2009
30 Novell eDirectory Tuning Guide for UNIX* Platforms
Loading...