Unsolved
This post is more than 5 years old
61 Posts
0
1034
August 8th, 2012 08:00
Feedback for Perfcollect v4.0
Hi folks,
I'm in the midst of a major revision opf perfcollect. My goals are to:
- add more Hyper-V related counters
- add some inquiry (INQ) utility output to increase visibility into the backend storage
- add some rudimentary foreign language capabilities (it's unclear whether I'll be able to get this done, though)
With regard to the Hyper-V related counters, there are already a couple dozen counters collected (see here for a list of all the counters collected by perfcollect), and I plan to add \Cluster Shared Volumes(*)\* to that list, but there are a few hundred more Hyper-V related counters that may or may not be interesting. I've compiled a list and put it here. We can't do all of them, but which would be important for sizing and high-level troubleshooting? Are there any counters specific to Windows Server 2012 that you'd like to see?
With regard to INQ, I plan to issue the following commands:
- inq -clariion (CLARiiON device information)
- inq -symwwn (Symmetrix device wwn and Serial Number)
- inq -sid -showvol (Symmetrix Volume Number and Serial Number)
Is there anything else you'd like to see in conjunction with perfcollect? This really would be for environment discovery, since an EMCRPTS host grab would be captured as a matter of course during troubleshooting, and that includes a very comprehensive list of INQ runs.
I hope to get this done and tested over the next month, and then I'll put it away for a little while.
And of course if there's anything else you'd like to see in perfcollect, now's the time to speak up!
--paul
pgaljan
61 Posts
0
August 8th, 2012 10:00
regarding isolating the log IO from DB IO:
There's no way to tell how much IO is going to a particular file from perfmon. But you could use the GetDBStats.sql script from my external blog. The DBA (or someone with a login to the database) has to run it. It's very quick.
It won't give you time-series data the way that perfmon does, but it will give you the total number of reads and writes at a file level. So if you have a LUN where perfmon indicates 1000 read and 500 write IOPs, and the math you do on the GetDBStats.sql output indicates that 20% of the write IO for a database is going to the log file, then you could reasonably conclude that log files represent about 100 write IOPs.
Kinda manual, but that's the way it shakes out if you don't separate your databases and logs.
pgaljan
61 Posts
0
August 8th, 2012 10:00
Ah, scalability and cross-platform. Very good points, and things that we are looking at in the short and long term. In the short term, we are investigating various methods for a framework that will query Active Directory and provide administrators a pick list for machines to evaluate. What happens in the background there is still TBD. The software might do remote WMI calls to collect data directly, or it might push perfcollect out to the hosts, remotely execute it, and then come back later to harvest the result. The are pros and cons to each. The remote WMI call method is clean and elegant, but could be flaky for a variety of reasons - the default state of Windows firewall being one of them. Also, collecting SQL perfmon counters would be difficult because the counter names are unique to the instance name (right now perfcollect does string searches against the list of counters avaiulable on the machine to collect the SQL stuff - the primary reason foreign language support hasn't been added yet).
The idea of pushing perfcollect out to the hosts is attractive because we could get the full complement of counters very easily, and it would be easy to add other applications like host grabs to the framework. But it is the less elegant of the two approaches, I suppose.
In the long term, there's definitely a vision to have a consolidated framework for data collection from Windows, *nix, and VMware hosts. We're baby stepping!