Sorry I let room for misunderstanding: PAV gives more addresses to a volume, hence it can lower the observed IO rate on a per address base. When looking at a volume the IO rate can go up indeed. Queuing is indeed what one needs to look at, VM performance tools however cannot show queues internal in a server, to help them, the server itself should be made PAV aware (Linux can, SFS/DB2 can't).
2009/4/1 Rob van der Heij <[email protected]> > 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/ > -- Kris Buelens, IBM Belgium, VM customer support
