statvv I/O per second vs statpd I/O per second

[walter_white]

I'm troubleshooting some performance issues and had a question..

When I run statpd -p -devtype FC -sortcol 9 -d 5 I'm seeing a tremendous amount of I/O on each PD..

2019-02-25_9-27-16.jpg (181.31 KiB) Viewed 12168 times

However, when I run statvv -sortcol 2,dec -ni I don't see the I/O match up.. I have over 6,000 I/O on my PD command and around 3,000 when I run the VV command.. I know these values are updating every 2 seconds but still there is a considerable difference..

I have a crap ton of queuing and trying to see exactly what I need that will fix it.. Simply adding some SSD? Enabling AO, etc.. I have one problem SQL server that is always crushing the I/O.. Wondering if I just address that, if possible, if it will fix it..

2019-02-25_9-29-11.jpg (128.64 KiB) Viewed 12168 times

Mainly though, I'm curious of the discrepancy above and would just like to understand it..

Thank you.

[MammaGutt]

Simplifying the shit out of this.

VV/VLUN is front end IOPS, PD is backend.

1 read IO on R1 VV = 1 IO on PD
1 write IO on R1 VV = 2 IO on PD
1 read IO on R5 VV = 1 IO on PD
1 write IO on R6 VV = 4 IO on PD
1 read IO on R6 VV = 1 IO on PD
1 write IO on R6 VV = 6.33 or 6.66 IO on PD (depending on set size and OS version)

Adding into the mix, any read hitting the cache will not cause IO on PD.
All writes hit cache in a health system and any write which is overwritten i cache before destaged to disk will not cause IO on PD.

Devils choice is deciding R5 over R6. R6 will cause more backend traffic demanding more backend IO capacity (ie HDD/SSD), which R5 is single parity which no vendor recommends anymore due to URE and longer rebuild time. Any new system should be sized for R6 unless you want trouble.