On Wed, Apr 1, 2009 at 8:35 AM, Kris Buelens <[email protected]> wrote:
> In any case, so not only paging: the model you'd use depends on the IO > rate. If you need lots of space with low IO rates: bigger models don't > penalize you. PAV will lower the observed IO rate. PAV lowers the observed I/O rate? Where do you observe that? If you create 2 exposures to the same volume, you'd expect to do *more* I/O per second in peak periods. Thus effectively lower your net I/O response time. You may not fully double the throughput, so when PAV spreads the load well, you'd see each of the subchannels take less than the single one before. But since that's only part of the story, the I/O rate per subchannel is not a helpful metric. And if you're not getting pretty close, you might question whether PAV was a good investment there. Really, only when your performance monitor shows you I/O queue time for the device, PAV could make sense (if that I/O is relevant for your service levels). As you say, many applications represent a single requester and don't queue where PAV would be able to help. But even if the application could, the workload may not be such that it actually happens. That's why it makes sense to start from the other end: look at what impacts the service levels of your critical workload. Rob -- Rob van der Heij Velocity Software http://www.velocitysoftware.com/
