Tip

Troubleshooting Jet session issues for Active Directory databases

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

    Requires Free Membership to View

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.

More AD database basics

Performing an offline defrag of the Active Directory database

Troubleshooting Active Directory database errors 

More info: AD design and administration resources

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.

Return to part one, Understanding AD operations: The Jet database

ABOUT THE AUTHOR
Gary Olsen is a systems software engineer for Hewlett-Packard in Global Solutions Engineering. He authored Windows 2000: Active Directory Design and Deployment and co-authored Windows Server 2003 on HP ProLiant Servers. Gary is a Microsoft MVP for Directory Services and formerly for Windows File Systems.


This was first published in August 2010

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.