.blg File Unable to Read Counter Information

In a recent state of affairs, I was tasked past a client to check i of their servers which they believed to be grossly over-provisioned. As a VM they knew they could easily pull both CPU and RAM from the server if they could make up one's mind the true needs of the server.

One of the items I regularly recommend to my clients is to have a "permanent" Perfmon collector log, where a bones set up of counters is collected every v minutes, with the log file cycled every day. This generates one.5MB-2.0MB of files daily (a trivial amount of storage even if maintained for several years) and daily cycling makes the logs easier to handle when troubleshooting issues. This is also useful for something about people don't have - a baseline over time - but to utilize it this way requires some serious finagling as you lot volition run into.

The style I ready the collector past default, the collector writes to a file in a designated directory, and I use a couple of batch files that use the logman command to stop and get-go the collector, and so a pair of Windows Scheduled Tasks, one to finish and commencement the collector each night (effectively cycling to a new output file) and i to start the collector on server start-upward (and then that a server reboot doesn't kill the collector birthday). I know there are ways to configure a collector to wheel to new files each mean solar day, but they are version-specific based on your version of Windows, while the batch file/scheduled chore method works beyond O/S versions.

The cyberspace outcome of this method is that y'all cease upwards with a directory with a large stack of blg files like this:

You can see a file for each day plus a new file any time the Server restarts. This is great when you are looking for info of what happened on the night of 05/24/2014, simply non and so much when y'all need to know what happened over the last xxx days.

Enter relog!

Relog is a command line utility for manipulating perfmon output files (either .blg or .csv). It is frequently used to filter existing files by counter or to convert .blg files into .csv files, both of which are described in this blog post and this 1 by John Pertell (blog/@jayape). A bottom known use of relog is its ability to combine individual files into a unmarried larger file, like this:

relog day1.blg day2.blg day3.blg -f BIN -o Day1_2_3.blg

...which would combine the three files day1, day2, and day3 into a unmarried big file Day_1_2_3.

This is a necessary evil for many types of analysis since it can be difficult to wade through multiple perfmon log files at once. Near tools merits to support information technology, but nigh of them also have vague disclaimers that amount to YMMV. The nearly reliable way to handle this state of affairs is to apply relog to combine the files prior to kickoff the assay.

In the given situation, I had 43 files roofing a lilliputian more than a calendar month to clarify. I hadn't collected this many files at once before, but didn't really think about information technology as whatsoever large deal. I used notepad to mock together the relog command (not for the faint of heart):

C:\PerfLogs\Blog>relog Ntirety-SQLServerPerf_000066.blg Ntirety-SQLServerPerf_000067.blg Ntirety-SQLServerPerf_000068.blg Ntirety-SQLServerPerf_000069.blg Ntirety-SQLServerPerf_000070.blg Ntirety-SQLServerPerf_000071.blg Ntirety-SQLServerPerf_000072.blg Ntirety-SQLServerPerf_000073.blg Ntirety-SQLServerPerf_000074.blg Ntirety-SQLServerPerf_000075.blg Ntirety-SQLServerPerf_000076.blg Ntirety-SQLServerPerf_000077.blg Ntirety-SQLServerPerf_000078.blg Ntirety-SQLServerPerf_000079.blg Ntirety-SQLServerPerf_000080.blg Ntirety-SQLServerPerf_000081.blg Ntirety-SQLServerPerf_000082.blg Ntirety-SQLServerPerf_000083.blg Ntirety-SQLServerPerf_000084.blg Ntirety-SQLServerPerf_000085.blg Ntirety-SQLServerPerf_000086.blg Ntirety-SQLServerPerf_000087.blg Ntirety-SQLServerPerf_000088.blg Ntirety-SQLServerPerf_000089.blg Ntirety-SQLServerPerf_000090.blg Ntirety-SQLServerPerf_000091.blg Ntirety-SQLServerPerf_000092.blg Ntirety-SQLServerPerf_000093.blg Ntirety-SQLServerPerf_000094.blg Ntirety-SQLServerPerf_000095.blg Ntirety-SQLServerPerf_000096.blg Ntirety-SQLServerPerf_000097.blg Ntirety-SQLServerPerf_000098.blg Ntirety-SQLServerPerf_000099.blg Ntirety-SQLServerPerf_000100.blg Ntirety-SQLServerPerf_000101.blg Ntirety-SQLServerPerf_000102.blg Ntirety-SQLServerPerf_000103.blg Ntirety-SQLServerPerf_000104.blg Ntirety-SQLServerPerf_000105.blg Ntirety-SQLServerPerf_000106.blg Ntirety-SQLServerPerf_000107.blg Ntirety-SQLServerPerf_000108.blg -f BIN -o Combined.blg

...and went to run it from the command prompt. Much to my surprise I received the following:

At first the error ("The specified log file type has not been installed on this computer") threw me and made me investigate whether i of the files was corrupted in some manner. All of the files were roughly the aforementioned size, with the days that had multiple files (due to server restarts) withal combining to exist nigh the same size. I collected smaller subsets of ii files/v files/10 files without issue. At this indicate I turned to my Google-Fu and quickly plant someone with a similar trouble. Microsoft employee Dustin Metzgar (web log/@DustinMetzgar) had a blog mail service from Baronial 2013 "Performance Monitor Problems" that described my situation exactly. Consequence #four in the post is "Combining several BLGs into one is limited to 32 files and has poor error letters" - audio familiar? Certain enough, if I modified my relog command to but include 32 files, it worked!

The item that Dustin doesn't address is how to handle the excess files. I institute that with a little inventiveness (very little) I was able to employ multiple relog commands to combine groups of files into larger files and and so combine those larger files into one last big file:

C:\PerfLogs\Web log>relog Ntirety-SQLServerPerf_000095.blg Ntirety-SQLServerPerf_000096.blg Ntirety-SQLServerPerf_000097.blg Ntirety-SQLServerPerf_000098.blg Ntirety-SQLServerPerf_000099.blg Ntirety-SQLServerPerf_000100.blg Ntirety-SQLServerPerf_000101.blg Ntirety-SQLServerPerf_000102.blg Ntirety-SQLServerPerf_000103.blg Ntirety-SQLServerPerf_000104.blg Ntirety-SQLServerPerf_000105.blg Ntirety-SQLServerPerf_000106.blg Ntirety-SQLServerPerf_000107.blg Ntirety-SQLServerPerf_000108.blg -f BIN -o Combined2.blg

C:\Perflogs\Blog>relog Combined1.blg Combined2.blg -f BIN -o Combined.blg

I was and then able to sift through the combined.blg file for the information covering the entire period easily. Later manual examination, I side by side loaded the blg file into the Performance Analysis of Logs (PAL) Tool for further analysis, but that is the subject area for some other blog post. 🙂

One item I haven't been able to run down yet is why the large output file (combined.blg) only has 11795 samples while the two input files have 12659 samples total. This would be expected beliefs/by design if I had applied some type of filter in the relog command, just in this instance I did not. You lot can see in the previous screenshots (from the initial relogs) that the input samples friction match the output samples exactly in those cases. If I discover an answer I will update the mail service with the information.

Hope this helps!

blackariervintend01.blogspot.com

Source: https://www.sqlservercentral.com/blogs/handling-perfmon-logs-with-relog

.blg File Unable to Read Counter Information

0 Response to ".blg File Unable to Read Counter Information"

Enviar um comentário

Iklan Atas Artikel

Iklan Tengah Artikel 1

Iklan Tengah Artikel 2

Iklan Bawah Artikel