On Tue, Mar 22, 2011 at 3:01 PM, Mark Post <[email protected]> wrote: > LVM striping, simply as a matter of course, doesn't make a lot of sense. I > would only recommend it in specific instances where performance requires it.
Did I hear the P-word? ;-) Interesting enough the original question did not mention that aspect.. I second your suggestion to reserve it for special situations. Rules of thumb from other platforms with different workload, different memory contention and different I/O architecture just don't apply well to a virtualized environment. The ideal workload for striping is when you're sequentially reading large files and reside on consecutive blocks on disk. Say you're reading 1 MB in a row, then it might be nice to make 4 disks work for you in parallel to read the data. Hopefully you don't expect throughput 4 times as high, but with the right wind you could remove some latency. Depending on the file system and how the file was created, the blocks of that file may not be next to each other on disk at all. When the blocks are scattered over the LVM volume, you may touch different disks anyway. We'd be talking about a workload wiht poor cache hit ratio. It rarely helps to get part of the data early, because when processing is sequential, the application will normally want the blocks in that order as well. It would be pretty sad to find that on a memory constrained system these additional blocks have been dropped from page cache already by the time the application comes looking for them. The number of FICON paths does not play a significant role. The number of ranks in the subsystem could be a factor, if you happen to have a say in that (if you stripe over more volumes than ranks, you simply end up in in the queue down there). And getting an excessive number of Linux devices involved in your workload has some memory implications as well. With low-utilized Linux guests on z/VM, I would not bother to do striping. I expect things to average out on the hypervisor level. If there is some specific part of the workload that needs to be improved, then analyze the requirements of that and make the necessary changes. Rob -- Rob van der Heij Velocity Software http://www.velocitysoftware.com/ ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
