This project has moved and is read-only. For the latest updates, please go here.

Customizing Instance name for PerfMon

Sep 17, 2010 at 4:00 AM
Edited Sep 17, 2010 at 4:04 PM

I'm technically using the native API, not ManagedEsent, but it seems general enough, and I'm not aware of a better place to ask general ESE questions.

Is there a way to customize the instance name for the Database object used by ESE to expose perfmon data? The application I'm working on can, and often will, have multiple processes with the same name, so it's difficult to differentiate between them using only the executable name. The database instance names are guaranteed to be unique across the different processes, but some of the stats I'm interested in are only under the Database object, not Database ==> Instances (though, this doesn't appear to be the case in Server 2k8 R2 and Windows 7). This is primarily for internal statistic gathering and publishing, so even if it was only uniquely identifiable through the HKEY_PERFORMANCE_DATA mechanism, that'd be great. Ideally, it'd be something that wasn't a system-wide setting, unlike the ProcessNameFormat setting. Alternatively, if there's another way of getting those stats, that'd be great, since I never particularly liked the PDH API anyway :)

Related to that question, is there something that has to be done to get the statistics to be published on a client OS (at least, Windows 7, haven't tried Vista yet)? The Database, Database Instances, and Database TableClasses objects show up in PerfMon when my application is running, but no instances appear. And, lastly, are these stats available on Server 2003? I know the option to disable the stats is only available on Vista and later, but I didn't know if that meant that they weren't published prior.


Sep 30, 2010 at 12:48 AM

No, unfortunately, there isn't a way to configure the label under the "Database" object in perfmon. It's always going to be <ProcessName> or, if you have multiple processes with the same name, <ProcessName>#<Number>. Which counters are you specifically interested in collecting under "Database"? I ask because some of them are actually accumulations of the "... ==> Instances" counters.

The counters should be visible on client OSs starting with Windows 7, I believe.

For Windows 2003, you need to enable them. Try this (note you'll need to find <EsentPrfDllDir> and <EsentPrfIniDir> below)...

unlodctr ESENT
reg.exe add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ESENT\Performance" /v "Open" /t REG_SZ /d "OpenPerformanceData" /f
reg.exe add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ESENT\Performance" /v "Collect" /t REG_SZ /d "CollectPerformanceData" /f
reg.exe add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ESENT\Performance" /v "Close" /t REG_SZ /d "ClosePerformanceData" /f
reg.exe add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ESENT\Performance" /v "Library" /t REG_SZ /d "<EsentPrfDllDir>\esentprf.dll" /f
lodctr "<EsentPrfIniDir>\esentprf.ini"


Oct 5, 2010 at 2:29 AM

The counters under Database I was interested in were Database Cache % Hit, Database Page Evictions/sec, and Database Page Fault Stalls/sec, which are newly available under Database ==> Instances (which confused me a bit since I thought those were related to global parameters, unless Win7 made the database cache size customizable to each instance?).

Also, that worked great on Windows 2003, thanks. As for Windows 7, is there a certain permission the process needs to have in order to add the counters? It looks like if I start from an elevated command prompt, the counters will appear, but otherwise they won't. I've only ever consumed counter data, never produced it, so sorry if this is a silly question. This also is a 32-bit application, so I don't know if that changes anything.

Thanks again.

Oct 5, 2010 at 5:58 PM

Even though the ESENT cache is still global (so no separate configuration per instance, sorry), it can tell which instances the pages in question (being hit, evicted and stalling) belong to, so it now reports those numbers per instance as well.

Regarding the elevated command prompt, yes, that makes sense now. ESENTPRF.DLL talks to ESENT.DLL via file mapping and that requires elevation in order to succeed.