Troubleshooting Jet session issues for Active Directory databases

http://searchwindowsserver.techtarget.com/tip/0,289483,sid68_gci1518687,00.html

Part one of this short series broke down the basics of the Active Directory Jet database, with tips on how to do an offline defrag and repair common database issues. This next article focuses primarily on Jet sessions and their affect on Active Directory database performance.

While memory and processor resources are important when processing database requests, there are other resources to consider, such as Jet sessions. MSDN defines a Jet session as follows:

"A session is the transaction context of the database engine. It can be used to begin, commit, or abort transactions that affect the visibility and durability of changes that are made by this or other sessions. A transaction can be started using JetBeginTransaction. A session may be created using JetBeginSession. The maximum number of sessions that can be created at any one time is controlled by JET_paramMaxSessions, which can be configured by means of JetSetSystemParameter."

Furthermore, a Jet session is single-threaded and opened when a database action is needed, such as for a read or write operation. If a thread is not cached, a new session is opened for the needed thread.

It is possible to run out of sessions. One of the events that indicate this condition is Event ID: 7 Source: KDC in the system event log. This event usually says "out of memory," but in my experience it is actually out of Jet sessions. Running out of sessions usually indicates a heavy load of requests that exhausts the session limit. It could also mean a number has been held open for a long time (such as the case when enumerating large group membership). This has the potential to cause poor DC response and logon delays, slow LDAP queries, and so on, though I've not seen cases where the Event 7 (KDC) indicated such a problem. Still, it should be resolved.

Fixing this is like fixing any other DC performance issue; either increase the depleted resource or reduce the load. Part of the load could include third-party Active Directory monitoring tools. In one situation I worked on, we shut off the AD monitoring tool and the Event ID 7 disappeared. This is a positive indication that the Active Directory was heavily loaded -- at least for Jet sessions -- and the tool had pushed it over the edge.

It's fairly easy to reduce the load; you can shut off things using Active Directory or perhaps install another DC. But how do you increase Jet sessions? When working on an issue with Microsoft, we could not determine what resource was depleted (extensive performance tests revealed there was plenty of available memory in spite of the "out of memory" indication in the event). We eventually discovered that Jet sessions are tied to the number of processors. While Microsoft indicated it would publish this, I was permitted to provide this to our customer.

While there are several variables that affect the Jet session limit, the only one affecting hardware resources is the CPU count. The table below shows the relationship between the number of processors and the Jet session limit. I'm not aware of a way to tell how many sessions you are using, but looking at the table, if you have four processors and are running out of sessions, then I'd add four more processors.

CPU COUNT	MAX JET SESSIONS
1	69
2	81
4	105
8	153
16	249
32	441

So this is great information and all, but wouldn't it be nice to have a registry hack that would increase the Jet sessions? There is -- In Windows Server 2008 R2 only. To change the limit, follow this procedure provided by Microsoft:

1. In Regedit, go to HKeyLocalMachine\SYSTEM\CurrentControlSet\Services\NTDS\Parameters.
2. Create a new DWORD value called Maximum Allocated EDB Sessions per Thread.
3. Valid values are 3 to 50 decimals. This registry value controls the first variable in the formula for determining the maximum amount of Jet sessions.
4. If no value exists, or it does and is less than or equal to 3, then 3 is used for the formula: 3*(15+4+4*CpuCount)
5. Setting Maximum Allocated EDB Sessions per Thread to 10 would change the formula to: 10*(15+4+4*CpuCount)

There is a caution with this method, however, because you are tweaking a database resource that may have impact elsewhere. I'm not sure how many -- if any -- production systems have set this resource, so it is advised to move this carefully. The default-first variable in the formula (i.e. for Windows 2008) is 3. So raise it to 4 and see if that resolves the problem. But again, it's hard to say what changing this value without increasing CPUs will do to performance.

So there you have it, a quick lesson on Active Directory database operations. It's pretty simple really, but very important to understanding AD health.