On the DMX you lose a resonable chunk of things you might be used to, optimizer is surely one of my old friends.  I’ve been strugglilng a bit with  performance, not because VP is slow but tracking things back to a source is such a massive pain in the ass.  WLA don’t seem to know much about VP, so you now have an added layer of abstraction you have to find.  SO if I’m beating a 48x of my SATA drives in a pool into submission at 100 wonderfully even spread iops per spindle… finding the guy who is doing it becomes a click nightmare.   I’ve got close to 1500 tdevs attatched to that pool and I’ve got to go look at every single one of them (or at least select all of them) and they don’t all have to be nice contiguous numbers, some tdevs might belong to another pool so you’ve got to exclude them.  Additionally there is no way to tell which one is nicely spread across all the drives in pool and which one has started doing random iops across concentrated to a subset of the pool… because someone had written out data when the pool was at 48 spindles rather than the 100+ it is now.   So you see a subset of disks get hot in a pool, so who’s doing it?  You have to map the 1500 tdev’s to the physicals and try to look for a peak/valley at the same time.   I’m pretty sure I’ve got a “fix” for the unbalance in the new microcode (unfortunately not the who part)…but I’ll have to wait to make and let it cook for a while to see if my suposition will work.  The new DMX code that came out in Feb, now has the same option as the vmax to drain datadevs, but unlike the vmax the new dmx code doesn’t (to my knowledge) rebalance the pool.  But if I can drain a datadev and it redistributes the data across the whole pool; I am sure I can create a script to walk through the pool one datadev a time removing it then adding it back in before going to the next.  This should redistribute things resonably well… if you wanted to get adventurous you could had a group of new datadevs (10-30 or more) at the beginning then remove them at the end so that there isn’t one datadev that is really unbalanced compared to the rest.

What I’ve found as the best way to try and find performance info is to do things in two separate methods:  use symstat to get realtime data and then combine that with the WLA  trailing perf data.   I do some symdev & symcfg magic foo to just get the tdevs bound to a paticular pool throw it into a sym device group and then when I no of something going on I run symstat against it.  Unlike WLA when you do that it will combine all the metamember data points into the meta head.  I can normally then pick out the offender relatively easily… but unfortunately not everything happens while you are watching so then its back to the click, click, click of WLA selecting tdevs unless your lucky enough to have an existing automation report around and you haven’t changed the tdevs against the pool (which for me hardly ever happens).