Re: Shark to FAStT performance?

From: jeff barratt-mccartney (jbarratt_at_COMPSAT.COM)
Date: 08/25/04

  • Next message: jeff barratt-mccartney: "Re: Shark to FAStT performance?" 
    Date:         Tue, 24 Aug 2004 20:55:20 -0400
To: aix-l@Princeton.EDU

    14 disk arrays? how big are the drives? have you tested rebuild times?

    -----Original Message-----
    From: IBM AIX Discussion List [mailto:aix-l@Princeton.EDU]On Behalf Of
    Jason delaFuente
    Sent: Tuesday, August 24, 2004 10:13 AM
    To: aix-l@Princeton.EDU
    Subject: Re: Shark to FAStT performance?

    FYI....
    Spanning across multiple 14 drive arrays in the FAStT helped significantly.

    Jason de la Fuente

    >>> JNguyen@WM.COM 08/23/04 04:13PM >>>
    We have a similar problem on the ESS disk before; The disk that was at 100%
    busy had no i/o read/write activity. Our fiber device driver and SDD was
    down level. We updated both SDD and fiber device driver and have not seen
    the problem since.

    Joseph

    -----Original Message-----
    From: IBM AIX Discussion List [mailto:aix-l@Princeton.EDU]On Behalf Of
    Jason delaFuente
    Sent: Monday, August 23, 2004 3:35 PM
    To: aix-l@Princeton.EDU
    Subject: Shark to FAStT performance?

    We moved 3 200 GB (approx) Volume Groups from an ESS Shark (F20) to a FAStT
    700 this weekend. The VG PP size was 8MB on 16GB LUNS when it was on the
    Shark. We consolidated to 4 50GB LUNS with 32GB PP Size when we moved to
    the FAStT. This morning the box was slammed. All but one of the disks was
    at 100% utilization and the box was showing around 90% wait I/O. This was
    being caused by a batch job that normally runs in about an hour. After 5
    hours it was still running. The Cache Hit ratio on the FAStT ranged from
    about 20%-40% percent for the LUNS in question with 99% of the I/O being
    reads.

    All of the new FAStT LUNS were on a 7 disk RAID5 array. This is the first
    time moving something of this magnitude from the Shark to the FAStT (Oracle
    DB). The first thing that we are trying is creating 14 disk RAID5 arrays and
    spanning the LUNS across those instead of just the one 7 disk array. On the
    FAStT we also changed the cache block size to 16 from 4 which helped the hit
    ratio and set the read ahead to 0.

    We have never had any need to tune any device attributes (hdisks, dar) on
    our systems. I think spanning the data across more physical disks is going
    to help I'm just not sure how much at this point. If anyone have any ideas
    or input on the situation I would greatly appreciate it.

    Has anyone experimented with the load_balancing attribute for the dar
    device?

    Thanks!

    Jason de la Fuente

  • Next message: jeff barratt-mccartney: "Re: Shark to FAStT performance?"

    Relevant Pages