Re: Shark to FAStT performance?

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

  • Next message: ChunGuang Yuan: "from 5.2 to 5.1" 
    Date:         Tue, 24 Aug 2004 21:03:24 -0400
To: aix-l@Princeton.EDU

    #2. how is oracle layed out on the disks? are you/were you seeing
    contention? spreading out the disk may be a reasonable solution, but a
    better solution might be isolating/seperating filesystems in contention? is
    this filesystems/raw devices? following OFA or ?

    -----Original Message-----
    From: IBM AIX Discussion List [mailto:aix-l@Princeton.EDU]On Behalf Of
    Jason delaFuente
    Sent: Monday, August 23, 2004 4: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: ChunGuang Yuan: "from 5.2 to 5.1"

    Relevant Pages

    • Re: Shark to FAStT performance?
      ... Subject: Shark to FAStT performance? ... Spanning across multiple 14 drive arrays in the FAStT helped significantly. ... We have a similar problem on the ESS disk before; The disk that was at 100% ...
      (AIX-L)
    • Re: Shark to FAStT performance?
      ... Spanning across multiple 14 drive arrays in the FAStT helped significantly. ... We have a similar problem on the ESS disk before; The disk that was at 100% ... We consolidated to 4 50GB LUNS with 32GB PP Size when we moved to ...
      (AIX-L)
    • Re: delete drive FastT
      ... remove the disk from ODM, rmdev -dl hdisk11 ... go to fastT storage manager, remove the hdisk11's mapping and delete ... equivalent to datavg1. ...
      (comp.unix.aix)
    • Re: Shark to FAStT performance?
      ... We have a similar problem on the ESS disk before; The disk that was at 100% ... We updated both SDD and fiber device driver and have not seen ... Subject: Shark to FAStT performance? ... We consolidated to 4 50GB LUNS with 32GB PP Size when we moved to ...
      (AIX-L)
    • Re: HP EVA4000 / IBM DS4300 / EMC CX3-20/40
      ... disk array with the virtual raidsets on top. ... So, the system admin, and the DBAs had to create and manage lots of ... separate LUNs and *manually* manage the performance among them to ... applications on the SAN. ...
      (comp.arch.storage)