Re: VIOS and Perf Monitoring

Since VIOS is a subset of AIX there are not any really good tools to monitor I/O there. lvmstat may be the best way to figure that out. I have not checked to see if that command is in VIOS, but it may be, it's a staple in AIX. I don't know if MPG's power tools can monitor VIOS, I know they have one that monitors most Unix variants.

Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


On 8/25/2011 9:07 AM, Kirk Goins wrote:

Not that all this isn't good discussion<grin>, but my original question was
basically how to measure disk performance at the VIOS level? If I didn't
use VIOS and hosted all my IBM i on top a IBM i partition I could use the
standard Performance Tools and things like WRKDSKSTS etc.



On Thu, Aug 25, 2011 at 5:06 AM, Jim Oberholtzer<midrangel@xxxxxxxxxx>wrote:

> Rob,
>
> You want to have a standard workload you can test with. At V7 use the
> wait accounting tooling built in to the OS. A very good test is loading
> PTFs from an image catalog. On smaller systems ( 4 or< drives) it is
> often faster to load the CDs one by one than use the image catalog. All
> I/O. I think it starts to even out at about 6 drives.
>
> Jim Oberholtzer
> Chief Technical Architect
> Agile Technology Architects
>
>
> On 8/25/2011 6:57 AM,rob@xxxxxxxxx wrote:

> > If I was to play around and unload/reload a lpar to test this, what would
> > be effective measuring?
> >
> >
> > Rob Berendt
> > -- Group Dekko Dept 1600 Mail to: 2505 Dekko Drive Garrett, IN 46738
> > Ship to: Dock 108 6928N 400E Kendallville, IN 46755
> > http://www.dekko.com From: Kirk Goins<kirkgoins@xxxxxxxxx> To:
> > Midrange Systems Technical Discussion<midrange-l@xxxxxxxxxxxx> Date:
> > 08/24/2011 05:04 PM Subject: Re: VIOS and Perf Monitoring Sent by:
> > midrange-l-bounces@xxxxxxxxxxxx According to multiple IBM and NON-IBM
> > sources the answer is along these lines... The OS has no idea if these
> > disks are real or virtual. The OS will only queue so many I/Os per
> > disk arm available ( I think I got that right ). So if the OS only
> > sees one 280GB disk it will not handle I/O as well vs having eight
> > 35GB disk arms. Now the actual number of real disks arms will affect
> > how well this concept works. On Wed, Aug 24, 2011 at 1:17 PM,
> > <rob@xxxxxxxxx> wrote:

> >> > I am still not getting why the OS needs to see multiple arms if they

> are

> >> > all virtual. Instead of one bigger virtual. It's still physically

> > spread

> >> > across the multiple arms defined either in VIOS or your hosting

> > partition.

> >> > Is it some weird thing like "let's calculate your journal receiver

> size

> >> > based on the number of arms you have"?
> >> >
> >> >
> >> > Rob Berendt
> >> > --
> >> > Group Dekko
> >> > Dept 1600
> >> > Mail to: 2505 Dekko Drive
> >> > Garrett, IN 46738
> >> > Ship to: Dock 108
> >> > 6928N 400E
> >> > Kendallville, IN 46755
> >> > http://www.dekko.com
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > From: Kirk Goins<kirkgoins@xxxxxxxxx>
> >> > To: Midrange-L<midrange-l@xxxxxxxxxxxx>
> >> > Date: 08/24/2011 04:12 PM
> >> > Subject: VIOS and Perf Monitoring
> >> > Sentby:midrange-l-bounces@xxxxxxxxxxxx
> >> >
> >> >
> >> >
> >> > I am getting ready to build a system with VIOS as the Hosting OS and

> > will

> >> > be
> >> > running several IBM i partitions. I know I should use several

> smaller

> >> > virtual disks vs 1 big one per partition so the IBM i OS wil see

> > multiple

> >> > disks/arms. So lets say I have 4 IBM i Partitions all on top of

> VIOS.

> >> > Each
> >> > partition will see 8 35GB drives and lets say there are 24 139GB ( or
> >> > whatever size VIOS wants to call them ) drives available to VIOS to
> >> > allocate
> >> > disk space with. So lots of room but could use more arms. Now I

> start a

> >> > really disk intensive process on 2 partitions. How can I tell how

> busy

> > the

> >> > drives really are at the VIOS level? On a partition with IBM i

> hosting I

> >> > can
> >> > do WRKDSKSTS on the base IBM i. Just wondering how to approach disk

> perf

> >> > issues inthe future.
> >> >
> >> > Thanks
> >> >
> >> > --
> >> > Kirk
> >> > --