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 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.

Running the ndstrace -c threads command returns the following thread pool statistics:

  • 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.

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.