slow vio disk - Aix

This is a discussion on slow vio disk - Aix ; Hi, I connect one lun from EMC cx500 to vio over FC adapters. This disk is used from one LPAR like datavg for DB2. Rootvg for that lpar is on vio's local disks. Now and then disk for db2 is ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: slow vio disk

  1. slow vio disk

    Hi,

    I connect one lun from EMC cx500 to vio over FC adapters. This disk is
    used from one LPAR like datavg for DB2.
    Rootvg for that lpar is on vio's local disks. Now and then disk for
    db2 is very slow, rootvg disks never. When I look at vio lpar I have
    hdiskpower0 at 100%tm_act ( from iostat ) when hdiskx is on 100%
    tm_act on lpar. So I presume that problems are between vio and cx500.
    Have anyone some hints? Is there something to setup manualy on vio for
    EMC drivers ( powermt commands work ok ).

    Regards

  2. Re: slow vio disk

    On Nov 29, 4:10 am, Kralj wrote:
    > I connect one lun from EMC cx500 to vio over FC adapters. This disk is
    > used from one LPAR like datavg for DB2.
    > Rootvg for that lpar is on vio's local disks. Now and then disk for
    > db2 is very slow, rootvg disks never. When I look at vio lpar I have
    > hdiskpower0 at 100%tm_act ( from iostat ) when hdiskx is on 100%
    > tm_act on lpar. So I presume that problems are between vio and cx500.
    > Have anyone some hints? Is there something to setup manualy on vio for
    > EMC drivers ( powermt commands work ok ).


    It could be that the application that is using the disk in the LPAR is
    keeping the disk 100% busy rather than being a hardware problem. EMC
    CLARiiON units also require some CLARiiON specific software to be
    installed in addition to PowerPath. Have you verified using the
    powermt command that all of the paths are available and that I/O is
    being balanced across the paths? Are the volumes being presented from
    the cx500 to the LPAR all controlled by the same SP in the cx500?

  3. Re: slow vio disk

    On Nov 30, 3:26 pm, dhoff...@kc.rr.com wrote:
    > On Nov 29, 4:10 am, Kralj wrote:
    >
    > > I connect one lun from EMC cx500 to vio over FC adapters. This disk is
    > > used from one LPAR like datavg for DB2.
    > > Rootvg for that lpar is on vio's local disks. Now and then disk for
    > > db2 is very slow, rootvg disks never. When I look at vio lpar I have
    > > hdiskpower0 at 100%tm_act ( from iostat ) when hdiskx is on 100%
    > > tm_act on lpar. So I presume that problems are between vio and cx500.
    > > Have anyone some hints? Is there something to setup manualy on vio for
    > > EMC drivers ( powermt commands work ok ).

    >
    > It could be that the application that is using the disk in the LPAR is
    > keeping the disk 100% busy rather than being a hardware problem. EMC
    > CLARiiON units also require some CLARiiON specific software to be
    > installed in addition to PowerPath. Have you verified using the
    > powermt command that all of the paths are available and that I/O is
    > being balanced across the paths? Are the volumes being presented from
    > the cx500 to the LPAR all controlled by the same SP in the cx500?



    Have you installed the EMC ODM software for PowerMPIO ?
    As already mentioned - do you have dead pathes or outstanding IO ?
    Check with
    $ powermt display dev=all

    And you are sure that the problem is not related to DB2 ?

    BTW: What type of disk is used on your cx500 ?

    hth
    Hajo

  4. Re: slow vio disk

    On Thu, 29 Nov 2007 02:10:41 -0800 (PST), Kralj
    wrote:

    > So I presume that problems are between vio and cx500.
    >Have anyone some hints? Is there something to setup manualy on vio for
    >EMC drivers ( powermt commands work ok ).


    Check queue depth settings and powerpath configuration.

    How are you passing the LUN to the client LPAR? As a whole LUN or are
    you parcelling out LVs to the client LPAR?

    Also check queue depth on the client (vscsi) and remember that all
    your work from the client will go through one VIO server. This
    shouldn't be a problem as long as the VIO server has sufficient CPU
    resources.

    -- David

+ Reply to Thread