Raid5Drives parameter

Jun 20, 2013 at 10:38 PM

I'm trying to determine how PAL is using the parameters for RAID5 or RAID1. I.e., if you enter NULL, or guess incorrectly, which alerts or stats are affected ?

Jun 24, 2013 at 7:00 PM
I was able to pop open the threshold files. And from what I can tell while RAID arrays affect real life counters, such as Disk Transfers/sec, the only portion of the PAL analysis that varies with the RAID5 or RAID1 drives parameter is the calculated IOPS.

If anyone has a better or more clear explanation, please let me know. Thanks.
Jul 10, 2013 at 5:47 AM
Yes, it only effects that one analysis. Its just there to do a "calculated IOPS". It's optional.
Dec 19, 2013 at 8:32 PM
Hi again,

I noticed this entire section disappeared in the latest version 2.4. I found this useful.

Any plans to bring it back?

Jan 15, 2014 at 7:47 PM
Oh, sorry. I didn't realize anyone was using it. I received no feedback on it other than most people asking why it is there.
What is the need that you are trying to solve? Maybe we can find a better way of doing it. I still have the code, so easy enough to add it back, but I'd like to hear about how you are using it first. Thank you.
Jan 15, 2014 at 9:02 PM
I work for an ISV, supporting on-premise enterprise software. We use perfmon/ PAL to answer the question "why is it so slow?" Specifically for the IOPS counter, it's extremely useful to use, in conjunction with the 'Avg Disc Sec...' counters to see if a client environment's storage is overloaded. It helps the conversation with our clients to say "hey, your SAN really should be able to have a lower 'avg disc sec' counter if this machine is only using 200 IOPS".

Hope this helps. Thanks.
Jan 16, 2014 at 9:56 PM
Ah, the ye olde, why is the disk slow issue. Many people have devoted their careers to disk management. It's quite complicated.
I have an upcoming book on this subject called, "The Microsoft Windows Performance Analysis Field Guide" due out later this year.

IOPS are nice to know, but it really depends on the queue length, IO sizes and response times. For example, a standard (no-cache) 7200 RPM disk drive will do roughly 343 IOPS at 16 KB random write IOs, 263 IOPS at 64 KB IO sizes, or 73 IOPS at 1 MB IO sizes. Same disk different IOPS depending on the IO sizes. The smaller the IO, the more IOPS, but less data transferred per second. The larger the IO size the more data can be transferred per second, but the larger the IO size, the longer the response times are going to be (Avg. Disk sec/Transfer). This is why it is common to see backup software, database servers, and anti-virus software reading and writing at 64 KB or larger IO sizes.

This is why I created the \LogicalDisk(*)\Disk Overwhelmed analysis in the PAL tool. It takes the Avg. Disk Queue Length, Avg. Disk sec/Transfer, and Avg. Disk Bytes/Transfer into account. The queue length is just to know if there is work to do or not (the actual size of the queue doesn't matter), and then the average response times of the IO with the IO size considered. So, whether its laptop hard drive or an enterprise SAN, the formula works.
Jun 11, 2014 at 3:53 AM
Getting IOPs out of the report would be a dream come true.
Jun 20, 2014 at 5:12 PM
I believe I've seen calculated IOPS back in v 2.5.

Clint, the calculated IOPS is very useful to me. I primarily use PAL for SQL Server and often my customers want to know "How many IOPS am I getting". This is especially so once they start talking to storage engineers about planning for hardware upgrades.

Thanks again, I love this tool!

Jul 4, 2014 at 12:08 AM
Thanks, Jon.
Well... I can send you an older threshold file with the Calculated IOPS analysis. I can't attach it to this response, but email me if you want it. My email address is Thank you.