Unfortunately, there is not much written that documents AD performance issues and how to use these counters. This TechNet overview article is a good place to start. There are two main objects to monitor:

1. Information related to the NTDS Object:

http://technet2.microsoft.com/windowsserver/en/library/6a2abace-5fab-49f0-8c6d-5daea891a5f71033.mspx?mfr=true

2. Information related to the Database Object:

http://technet2.microsoft.com/windowsserver/en/library/26bfde1e-7938-4573-b12f-6e4e9cedf4a51033.mspx?mfr=true

The following represents Microsoft’s recommendations when monitoring Domain Controllers:

http://technet2.microsoft.com/windowsserver/en/library/c5d72b6f-5974-4263-b29f-2eece0ab44371033.mspx?mfr=true

It will at least help you get acquainted with the basic terminology that AD uses.

04/14/08-13:44:04 – Event ID: 2900, Category: Perf Text, Severity: Error Insufficient data in performance name table

Concerning the message “Insufficient data in performance name table” refers to the file perfc009.dat that resides in the <Windows>\system32 folder. This file contains the names of all installed objects and counters. The name table can become corrupted during installation of new or modified Counter definitions using the lodctr utility.  Even though Microsoft enhanced the procedure to rebuild a  damaged perfc009.dat file in Windows Server 2003 ( KB 300956)  and these problems typically impact all consumers of performance counters, the Performance Sentry Collection Service was modified to recover from severe damage to the perfc009.dat that it finds during Discovery and continue processing.

As an alternative, to the Microsoft KnowledgeBase entry, we sometimes suggest to our customers that they simply copy a Perfc009.dat file from a similarly configured server (after renaming the existing corrupt Perfc009.dat file – for backup or supporting documentation for the error).You can verify the fix by starting Perfmon (Performance Monitor) and looking at the performance counters.

Then stop and restart the Performance Sentry Collection Service so that service will re-initialize using the new, or repaired, file.

For additional repaired options you can read Microsoft’s knowledge base article: KB 300956

Ever notice all those Messages that the Performance Sentry collection service writes to the Application Event log and the <computername>.ntsmf.log file? These messages are designed to help diagnose data collection problems. By reviewing the Perfomrance Sentry Collection service Application Event log Warning messages that document most of the more common data collection anomalies that occur, you can usually identify and resolve a data collection problem quickly. This FAQ tells you how to use these Warning messages to solve data collection problems.

Please follow this simple procedure whenever you have a problem collecting data. First, answer the question below, and proceed to the next page of instructions based on your answer.

Is the Counter you need visible using the Microsoft System Monitor?

Start an interactive System Monitor session and see if the Counter or Counters you need are visible.
If the Counter you need is visible in System Monitor, the Performance Sentry Collection Service should also be able to collect it.

If the Counter value you need is not visible in System Monitor, the Performance Sentry Collection Service probably cannot collect it either. However, it is quite possible that Performance Sentry will generate a diagnostic  error or Warning message that will help you understand why the data you are interested in cannot be collected.

Note that beginning in Performance Sentry version 2.4.5, the Performance Sentry Collection Service does not honor the Disable Performance Counters Registry flag when it is set. Neither will any action performed by the Performance Sentry Collection Service ever cause the Disable Performance Counters Registry flag to be set. However, when the Disable Performance Counters Registry flag is set, it may indicate there is an underlying problem with a Performance Library DLL that could effect Performance Sentry’s ability to gather the associated performance data.

Instead of Disable Performance Counters, Performance Sentry version 2.4.6 and higher utilizes a comparable facility that allows you to specifically exclude Performance Library DLLs that are troublesome. Specific Performance Library DLL excludes and includes are noted in a configuration file in the root NTSMFxx folder named DmPerfss.cfg.

Running Performance Sentry under MS Cluster Server

To run Performance Sentry under a Windows cluster environment:

1. Install the Performance Sentry Collection service in each member of the cluster. There is no need to define any Cluster Resource as a “Generic Application” or “Generic Service”. Performance Sentry will automatically begin to read all shared disks and resources defined by the owner of the cluster on the next collection interval when a failover occurs. MS Cluster Server is started as a service and it may take longer to start than other services in a cluster.

It is recommended that the Performance Sentry service starts after the MS Cluster Server is started so that Performance Sentry can “see” the presence of cluster share drives and logical disk in the respective nodes. This service dependency can be accomplished by adding a “DependOnService” registry value for the particular cluster server software under:
HKLM\System\CurrentControlSet\Services\Dmperfss

1. Prepare the machine you want to use to administer Performance Sentry.

Run the Setup program contained on the installation disk to install the Sentry Administration program on the Windows workstation or server you intend to use to administer Performance Sentry. Sentry Administration is used to define and activate performance Data Collection Sets (DCSes) on the local machine and any remote computers that you want to monitor.

A Data Collection Set defines (1) which of the available Performance Counters you want to collect, (2) the data collection interval and other runtime parameters that control the operation of the collection agent, and (3) the filtering options that ensure that you are collecting the right amount of information. The program ships with standard defaults that are appropriate for most environments. We also provide you with a large number of pre-defined DCSes that are appropriate for different application servers. With Sentry Administration, you can assign any of the DCSes we provided, use the DCS Editor to modify them in a jiffy, or create your own.

2. Prepare the machine you want to monitor.

Install the Performance Sentry Collection engine as a service on any Windows computer that you wish to collect information about and start it. The Performance Sentry Collection Service collects the performance data you specify on the Windows computer on which it is installed. You can install as many copies of the Performance Sentry service as you are licensed to run. By default, DMPerfss.exe writes an NTSMF format data file to a \Data subdirectory of the installation directory on the monitored system’s local hard drive. You can change the Data directory to point anywhere you want.

3. Automate the process for consolidating Performance Sentry collection files for processing by SAS ITRM, MXG, or other performance reporting packages.

Once installed, the Collection Service runs automatically from the time your Windows machine starts up until it shuts down. At the end of the collection cycle, Performance Sentry closes the current .smf data logging file to free it up for processing. It immediately opens a new collection file so no collection intervals are lost. At this time you can schedule a process to copy the older collection file to a central location for consolidation and processing. This may involve setting up a connection to a remote drive on a machine you designate as a central collection file consolidation point and scheduling a program to move the old collection files to that machine at regularly scheduled times.

If the machine being monitored is behind a firewall, it may be necessary to run a simple ftp script to consolidate the daily data files.

The standard installation package that we ship contains three separate Setup routines that can be run separately or together. One setup routine is used to install the Sentry Administration GUI which is used to administer NTSMF data collection. You can install as many copies of the Sentry Administration program as necessary to administer NTSMF across your network. (It is often helpful to run separate copies of Sentry Administration in front of and behind your firewall, for example.

The second setup routine is for the Performance Sentry Collection Service. You can run this setup routine right from the distribution or copy it to disk and run it separately. There is even a silent mode setup option so that you can install the collection agent unattended. Finally, the User Manual shows how to create a simple installation script that you can use to roll out NTSMF across your network of Windows machines. A scripted installation of the collection service has the advantage of being able to assign a Data Collection set (DCS) of your own during installation and also allows you to assign a User Account to be impersonated during Cycle End processingThe User Manual also provides a sample script to use to distribute the NTSMF collection agent using SMS.

For those customers who develop their own distribution and installation procedures, the required set of files needed to install the current version of the collection service is documented on page 17 of the User Manual.

Download the full User Manual (pdf)

Unable to copy the PSSMsg.dll file during installation. Running an installation script to upgrade the collection service, you are likely to find that the PSSMsg.dll file is in use and cannot be replaced. The PSSMsg.dll file is an application Event log message dll that is loaded and used by the Event Log service. Any other utility programs that you run that access the Event log are likely also to have opened the PSSMsg.dll file. In order to copy the latest PSSMsg.dll file, you may have to shut down the Event Log service and any other service that accesses Event Log message dlls. Make sure you restart these services after you complete the file copy successfully.

Please do not agonize over the fact that your script cannot replace the PSSMsg.dll file because it is in use. It is not the end of the world to run the most current collection service with a slightly out-of-date Event Log Message dll.

Optional runtime files. Diagnostic symbols are no longer included in the program’s binary executables like DMPerfss.exe and DTSFnd.dll due to Microsoft compiler changes. Diagnostic symbols are now found in filenames ending with a .pdb suffix. Installing these debug symbol files is optional, but highly recommended so that we can maintain the high quality of the collection service code.

Installing the enclosed version of PKZIP25.exe is also optional.

The runtime files can be found in the \Program Files\NTSMF31 folder following the installation of the collection service following setup, or in the folder \Program Files\Performance Sentry\Collection Sevice Files following the installation of Performance Sentry Administration component.

The third setup routine is for Performance Sentry Portal and Performance Database.   The Performance Database is a Microsoft SQL Server based database and the Performance Sentry Portal is an ASP.NET graphical interface to the database.

As Windows grew and became more robust, so did NTSMF and its capabilities to the point that it was no longer just a performance data collector, but a set of components built around the NTSMF data collection service.  NTSMF was rebranded as Performance SeNTry with the emphasis on ‘NT’.  With the arrival of Windows 2000 and especially Windows Server 2003, the emphasis on ‘NT’ was dropped and the software is now simply called ‘Performance Sentry’. 

You’ll still see references to NTSMF in some of our program and folder descriptions in homage to our long history with Windows from its origins as ‘NT’ to its present versions of ‘Vista’ and ‘Server 2008′.

In semiconductor fabrication, “stepping” refers to the chip manufacturing process which is called a stepper that deposits successive layers of etched material conducting material and insulation. Our best guess is that this is an internal reference to the plant/stepper technology that produced the chip.

The CPU configuration data in the Registry is actually a narrow subset of the information Intel places in WMI today. See for example, http://msdn.microsoft.com/en-us/library/aa394373.aspx for the complete win32_processor spec. See the table that documents the processor family. However, most of these fields are null when you query them in WMI, as in the following script, for example:

Set colSettings = objWMIService.ExecQuery _

(”SELECT * FROM Win32_Processor”)

For Each objProcessor in colSettings

    Wscript.Echo “System Type: ” & objProcessor.Architecture

    Wscript.Echo “Processor: ” & objProcessor.Description

    Wscript.Echo “Family: ” & objProcessor.Family

Next

will return a Processor Description identical to what is contained Registry, but Processor.Family is null.

There is a a new field available for some of Intel’s newer processors at HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\CentralProcessor\0\ProcessorNameString that may provide you with what you are looking for.

You can harvest this Registry value using the NTSMF Registry data collection feature. Add the HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\CentralProcessor\0\ProcessorNameString field name to the Registry values on the DCS Parameters “File Contents” Tab, as in the following illustration:

to gather the information stored in this Registry field.

Benchmark results consistently show that within a processor family, the performance of an Intel processor usually scales linearly with clock speed (in MHz), all other factors like cache size and bus speed being equal. Figure 3 below shows a chart which illustrates this point. Four representative sets of published benchmark results are plotted for Pentium II processors in the range of 300-450 MHz. That performance scales linearly as the clock rate increases is evident. Within a processor family, it is reasonable to expect a Pentium IV at 1.8 GHz to run roughly 50% faster than a Pentium IV 1.2 GHz box.

Figure 3. Within a family of processors, performance of Intel CPUs scales linearly with clock speed.

However, if  you try to compare machines from different processor families, you are apt to find that while clock speed is still important, there are other architectural features that matter. For instance, the 386, 486, Pentium, and Pentium Pro machines represent four different Intel processors families, the P3, P4, P5 and P6, respectively. The P4 introduced instruction pipelining to the Intel processor line, the P5 uses a dual integer pipeline (also known as a superscalar architecture), while the P6 features a highly parallel microarchitecture design. Running at similar clock speeds, P4, P5 and P6 machines will show markedly different results.

Since the advent of the first P6 Pentium Pro machines, subsequent versions of the Pentium II, III and IV are all P6 family machines with a similar internal microarchitecture. Machines within this processor family can be expected to scale roughly as a function of clock speed, as illustrated above. (In fact, Intel tweaked the internal architecture of the Pentium IV chip specifically to help it scale linearly with faster clock speeds.)

Intel has also introduced Itanium systems based on the 64-bit P7 architecture, which is vastly different from its predecessors. Our preliminary testing with an early Itanium running a pre-release copy of the 64-bit version of Windows XP indicates that P7 processors are much faster than its clock speed alone would lead you to believe.

Several aspects of typically memory leaks make them especially insidious programming bugs. A program with a memory leak is not obviously incorrect, and may even produce the correct output or calculate the proper results. Memory leaks are often not evident until a program has been executing successfully for hours, days, or weeks.  It is not always obvious which program is causing the memory leak. The memory leak may not manifest itself in the same way all the time. A program with a memory leak will eventually exhaust the supply of virtual memory pages available so that simple calls to allocate a new segment of virtual memory fail. When simple application calls to allocate a new segment of virtual memory fail, the results are often unpredictable. Finally, applications frequently make calls to allocate and free virtual memory. These calls are typically sprinkled in various spots in the program. Because system functions and DLL library routines also make frequent calls to allocate and free virtual memory, it is not easy to isolate what is causing the bug in the program. Fortunately, there are excellent automated tools for Windows application developers that can help programmers find many types of memory bugs. There is no excuse for not using some of these development and testing tools on your Windows 2000 applications in order to catch many types of memory leaks before they manifest themselves in critical product environments.

The procedure for finding a memory leak depends on what type of virtual memory is being allocated. The bug may be local to an application so that its only effect is on the process virtual address space where the leak is occurring. The bug may be in a shared DLL or other common module so that the bug will be manifest first in this application and then that one. Finally, the problem could be a leak affecting shared system memory, which can make it very difficult to pinpoint the specific application or module causing the leak. To diagnose a memory leak, be prepared to look at any or all of the following:

% Committed Bytes in Use. The Commit Limit is an upper limit on the amount of virtual memory that can be allocated on your system. The Commit Limit is tied to the size of RAM and the amount space defined for paging files (and remember that paging files can and do expand the system looks like it may run short of virtual memory). The % Committed Bytes in Use Counter reports Committed Bytes as a percentage of the Commit Limit. Whenever % Committed Bytes in Use exceeds 80-90%, application requests to allocate

per process Virtual Bytes. Virtual Bytes records the amount of virtual memory allocated by individual processes. If the program with the memory leak is allocating virtual memory in its own address space, the memory leak should be evident by tracking the per process Virtual Bytes Counter. If the amount of Virtual Bytes allocated for a process increases steadily over the life of a process, there is good reason to suspect a leak.

Pool Paged Bytes. Virtual memory for various system functions, including shared memory files (like DLLs), is allocated from the Paged Pool, which is an area of the system’s virtual memory that is limited in size. A program with a memory leak that is allocating, but never freeing memory from the Paged Pool will eventually exhaust the Paged Pool. Subsequent allocations that request the Paged Pool will then fail, with unpredictable (but predictably bad) results. The Pool Paged Bytes Counter in the Memory Object reports the current number of bytes allocated from the Paged Pool. The upper limit on the size of the Paged Pool is calculated by the system at start-up. This calculation can be overridden by setting the Paged Pool Limit explicitly using the Registry parameter PagedPoolSize at HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management. In either case, the upper limit on the size of the Paged Pool, according to Microsoft documentation in Windows 2000 Resource Kit is 192 MB in NT 4.0 and up to 470 MB in Windows 2000.

Pool Nonpaged Bytes. Some kernel functions and device drivers in particular require real memory buffers that can never be paged out of the system. These programs allocate memory from the nonpaged pool, which also has an upper limit.  A device driver with a memory leak will eventually exhaust the supply of Nonpaged Pool Bytes, which will cause subsequent allocations that request the nonpaged pool to fail. Running out of space in the nonpaged pool often results in a Blue Screen.