Optimal amount of pathes for Solaris 10?
just a question because i cant find proper answers.
Exist a recommendation for a amount of pathes per lun in solaris 10 (maybe 11) for an optimal use?
This is a good performance question. Most people usually sprout ROT (Rule of Thumb) answers which is where this 12 business comes from. Realistic it depends on the workload and the multipathing configuration used. I assume without HDLM you are using MPxIO (or less likely DMP).
- More path is better for a more highly random workload because its effect on internal queuing (in the OS) if we are seeing a high number of IOPS queues can fill which results in queued I/Os. From the arrays perspective, random is random, the algorithms can only do so much regardless down with path they come.
- There is a celling at which more paths becomes bad. As stated above when we have too many paths, we add overhead associated with testing and switching which will have SOME negative effect.
[*]MPxIO is by default optimised for workload distribution. Without customisation it is much better at handling random workloads. A lot of this is because of ALUA and the fact that per target optimisation is limited.
[*]DMP is much more capable; it has more target based intelligences and will deal with mixed workloads better!
[indent=1]So that said, how many paths should you use? The approach I normally take is to look at the workload.
[indent=1]If the workload is heavily sequential, go 4 paths (some would argue 2 here). Consider tweaking the load-balancing policy (maybe forgo round-robin here) and the region-size in MPxIO (this of course should also factor in block size). For DMP, generally do nothing.
[indent=1]If the environment is mixed, you need to consider the ratios and plan according.
[indent=1]A key thing to remember here is that the number of paths is just one part of the equation. Increasing and decreasing the paths will affect performance. That said, multipath software, its configuration and understanding the workload are also key points that offer more avenues for optimisation.
[*]Buy HDLM. It understand the workload better than you do and better than any 3[sup]rd[/sup] party product.
[*]Consider engaging professional services for help. Performance tuning is more complex than it sounds.
Thats a great answer. Thanks for that!
The question is based on some issues from redo luns into a big database. I know that we have to buy somethin. ATM it was a question where we cant find a answer. But the issues on mysite are also a bit to complex to answer it allone.
Oracle, this makes things even MORE complex. Are you using ASM?
No, we dont use it.
Which version of TC? What array is this modular or enterprise?
Dot no what you mean with "which version". Its an Enterprisesystem.
Which version of TrueCopy (TC). Given its enterprise its going to be TC (Sync). You should expect some latency using this technology. Why do you think the problem is in the software stack?
Its an "old" sequential system with an 13tb database. If there are TC Sync-Responsetimes from 0.2 instead of 0,1ms we get problems in the queues of that database. We habe "some" enterprisesystems and this host is the only one who run in problems with that.
Sounds reasonable. Can you capture some vmstat outputs to see if there is queueing occuring.
Well, I wouldn't make a haphazard change. You could make things worse. Wait until you can get the data and then analyse and move on.