Performance monitoring, MXPerformanceToolkit

Hi all,

I’m ruminating on a wholesale performance assessment. Looking around I think we have:

Fixlets for the FillDB performance log:

  • BES Support: 4778 Enable FillDB performance log
  • BES Support: 4779 WARNING: FillDB performance log is enabled

Via the MXPerformanceToolkit, we have MXPerfmon[.exe], which is a shim for logman.exe (on Windows; aka the cli interface for Performance Monitor aka perfmon.msc) and nmon` (on Linux).

On Windows, it seems that logman.exe has options for specifying start/end times for a named counter, and can use XML configuration files. While MXPerfmon.exe has options to display the configuration items, it doesn’t close the circle for start/end times, nor supply the bits for XML output.

Meanwhile, there’s an older KB article on manually creating Windows logman counters.

If one wants to have a coordinated performance sampling across the infrastructure (on Windows), it looks like we need to:

  • Deploy the FillDB performance log fixlets, per BF scheduling.
  • Configure logman counters with schedules.
    • For consistency
    • Use MXPerfmon to output the list of configuration items.
    • Feed that text to logman.exe, with additional options for start/end, exact names, etc, and output the XML file(s).
    • Distribute the XML files to infrastructure servers
    • run logman import with the XML file(s)
    • [This sequence could be orchestrated via custom fixlets]
  • Collect the data
    • UploadManager?
    • Run around and manually copy files?

And then, finally, analyze the output.

Am I missing anything? Anyone have better strategies?

Thanks!

This idea is related. (Not mine, but I voted and commented.)

BFP-I-560 BigFix Diagnostic Collection Tool

1 Like

Tagging @bigfix.mark, as the toolkit is his handiwork. :smiley:

I don’t have anything to add but I’ve been needing to investigate this further as well. We have been having a lot of issues where relays are saying that the server is busy and i’m thinking that it’s going to be traced back to either a filldb issue or some other issue with the root server being overwhelmed with check-ins, so i will be watching this thread closely.