With Analyzer do the I/Os shown at the disk level include the parity calculation I/Os? For instance 1 write I/O coming from a host will result in 4 I/Os (RAID 5) on the physical disks. Should I expect to see those 4 I/Os when looking at the disk in Analyzer or will I see just 1 I/O?
We also run analyzer 24/7. Works well for when you hear about performance issues days after they occurred. Ideally we'll use all the data to do some system wide trending as well. Currently working on automating that process with a sql database and custom reports.
If you see the I/O at front end you will just see the actual number of I/O's but if you look at the back end disk I/O's the "yes" you will definetly see the I/O's with write penalty.
Hi Jim, how was the weekend?
About iSCSI: unfortunately I don't have that much experience with it. The only time I encountered iSCSI I used it to copy data from a CX3 to another CX3 and the speed we got was about 30MBps, but then again, this was in the CX3 era, so about 5, 6 years ago or so. Back then colleagues of mine didn't get much more than 30MBps on a 1 Gb link either. So based on that I would say that FC work much more "clean" with less overhead so it can actually (almost) reach the theoretical maximum.
I wonder about the experiences of other people as well. Anyone?
Exactly: it wouldn't be much of an analyzer product if it didn't show this! You can also see the influence of the cache filling up and the watermark flushing and about everything you always wanted to know.
Question: in the licensed version of Analyzer you can enable the collection of NARs for a maximum of 30 days. What do you guys use to monitor continuously? Do you manually disable / enable the log collecting or do you have this scripted?
I created a script for this, but I encountered vague problems. What I see is that disableing is not really an issue, but when I re-enable too quickly, it sometimes fails and I end up with not collecting any logs. I was thinking about building in some sort of "pause" to be sure the array is ready for the new command or a second option was to first disable it on all my arrays and then enable it on all arrays (instead of dis/en it per array and move on to the next array).
How do you do this?
The way I do it is leave periodic archiving turned on. I then check to see if a NAR file was generated every hour (anaylzer -archive -all -path d:\narcollection\). I grab all files, this way if the script server is down for an extended period of time it will grab files that it missed. I then delete all the files from the array so they aren't downloaded again the next hour (analyzer -archive -delete -all -o).
I used to manually create the NAR files with the script. I found that we would have issues with the script host and we wouldn't get a NAR created in a time and thus not have data for a specfic timeframe. This method allows the NAR files to just be archived on the array until the script comes grab them.
Ok, but creating the logs will stop after 30 days, won't it?
To minimize the "holes" or "gaps" in the logging I restart the data logging before it actually automatically ends, so the gap will be minimal, except that scripting this doesn't work perfectly
Rob, you can unselect the "Stop data collection after" option. This will keep it running 24/7/365.
At some point in time, you'll end up with so many NAR files that it will start deleting the oldest, but that's no problem for me. I try to grab some NARs once every 1-2-3 months or so, save them locally and perform some basic checks. I just keep that as a history.
Depends on your settings. Here are my settings for one fo the arrays:
Archive Poll Interval (sec): 300
Real Time Poll Interval (sec): 300
Periodic Archiving: Yes
Current Logging Period (day): nonstop