Skip to main content

tracking inefficient queries...

update: a fellow reader suggested i check out this article from tony murray. it's good stuff, so i thought i'd drop the link here: logging ldap searches: ad & adam.

so... a couple of domain controllers had runaway lsass processes today. i began to look further into the issue and figured out where excessive LDAP queries were being issued from. unfortunately, it didn't amount to anything... but the process in tracking them was pretty useful. the first thing i should point you to is Server Performance Advisor. just a fyi, as it turns out, there's a management pack that you can use with SPA... :) it's located here.

alright, so spa... you're on your own. it's a little kludgy, but once you have it down, it's extremely useful for providing information. i'm not really happy about the fact that it has to leave a footprint (installed) versus just running from an executable... but what do you do? anyway, the stuff i realized in spa is that it doesn't capture long-running or inefficient queries. i did some more digging and found that if you raise the 15 Field Engineering level to 4 or 5, you get logging down to the query. you can read the whole article here. here's a snippet from the article:

Tracking Expensive and Inefficient Searches

Expensive searches are searches that visit a large number of entries. The efficiency of a search is measured by the number of entries returned against the number of entries visited. For example, a search that goes through 500 entries could be considered an expensive search. If the search returns 500 entries after searching through 500 entries, then you have an efficient search. An inefficient search returns five entries after searching through 500 entries.

To track searches, you can enable the diagnostic event logging for Active Directory Services. Event logging allows you to determine if you have expensive or inefficient searches.

These event log messages are logged in the Directory Services event log using the Field Engineering category. The Directory Services event log is generated every time the garbage collector runs.

The following is an example of an event log message of an inefficient search:

Windows 2000 Server log

The Search operation based at DC=MyTest,DC=microsoft,DC=com 
using the filter:
(attr(0xd)=<substr>)
visited 237 entries and returned 6 entries.

Windows Server 2003 log

Internal event: A client issued a search operation with the following options.

Client:
127.0.0.1
Starting node:
 DC=MyTest,DC=microsoft,DC=com
Filter: 
  (objectCategory=<val>) Visited entries: 237 Returned entries: 6

This search is considered an inefficient search because only six entries are returned after going through 237 entries.

Potentially, there can be numerous event log messages, so the messages are masked by using a severity level other than the default:

  • DS_EVENT_SEV_VERBOSE
    To log a message about the number of expensive and inefficient search operations performed in the last collection period, set the Field Engineering logging severity level to 4 (DS_EVENT_SEV_VERBOSE).
  • DS_EVENT_SEV_INTERNAL
    To log a message about the number of expensive and inefficient search operations performed in individual searches, set the Field Engineering logging severity level to 5 (DS_EVENT_SEV_INTERNAL). This event logs the exact filter used for each search operation that was expensive or inefficient, immediately after any expensive or inefficient search completes.

You can set the severity levels by setting the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\
Diagnostics\15 Field Engineering

For information about how to enable diagnostic event logging for Active Directory Services, see the Microsoft Knowledge Base article Q314980 How to configure Active Directory diagnostic event logging in Windows Server Services.

To categorize search operations as expensive or inefficient, two DWORD registry keys are used:

  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\Expensive Search Results Threshold
  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\Inefficient Search Results Threshold

These DWORD registry keys have the following default values:

  • Expensive Search Results Threshold: 10000
  • Inefficient Search Results Threshold: 1000

Using the default values, a search is considered expensive if it visits more than 10,000 entries. A search is considered inefficient if the search visits more than 1,000 entries and the returned entries are less than 10 percent of the entries that it visited.

Comments

Popular posts from this blog

using preloadpkgonsite.exe to stage compressed copies to child site distribution points

UPDATE: john marcum sent me a kind email to let me know about a problem he ran into with preloadpkgonsite.exe in the new SCCM Toolkit V2 where under certain conditions, packages will not uncompress.  if you are using the v2 toolkit, PLEASE read this blog post before proceeding.   here’s a scenario that came up on the mssms@lists.myitforum.com mailing list. when confronted with a situation of large packages and wan links, it’s generally best to get the data to the other location without going over the wire. in this case, 75gb. :/ the “how” you get the files there is really not the most important thing to worry about. once they’re there and moved to the appropriate location, preloadpkgonsite.exe is required to install the compressed source files. once done, a status message goes back to the parent server which should stop the upstream server from copying the package source files over the wan to the child site. anyway, if it’s a relatively small amount of packages, you can

How to Identify Applications Using Your Domain Controller

Problem Everyone has been through it. We've all had to retire or replace a domain controller at some point in our checkered collective experiences. While AD provides very intelligent high availability, some applications are just plain dumb. They do not observe site awareness or participate in locating a domain controller. All they want is the name or IP of one domain controller which gets hardcoded in a configuration file somewhere, deeply embedded in some file folder or setting that you are never going to find. How do you look at a DC and decide which applications might be doing it? Packet trace? Logs? Shut it down and wait for screaming? It seems very tedious and nearly impossible. Potential Solution Obviously I wouldn't even bother posting this if I hadn't run across something interesting. :) I ran across something in draftcalled Domain Controller Isolation. Since it's in draft, I don't know that it's published yet. HOWEVER, the concept is based off

sccm: content hash fails to match

back in 2008, I wrote up a little thing about how distribution manager fails to send a package to a distribution point . even though a lot of what I wrote that for was the failure of packages to get delivered to child sites, the result was pretty much the same. when the client tries to run the advertisement with an old package, the result was a failure because of content mismatch. I went through an ordeal recently capturing these exact kinds of failures and corrected quite a number of problems with these packages. the resulting blog post is my effort to capture how these problems were resolved. if nothing else, it's a basic checklist of things you can use.   DETECTION status messages take a look at your status messages. this has to be the easiest way to determine where these problems exist. unfortunately, it requires that a client is already experiencing problems. there are client logs you can examine as well such as cas, but I wasn't even sure I was going to have enough m