Re: Stripe sizing and maxcontig

John L <jl@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
Talk to your DBA. It is likely different parts of the database may be
suited by different configurations. With newer firmware, you have
much more freedom to tailor stripe size and so on differently on
each logical drive. Check the release notes on sun.com.

Hopefully he has a good DBA. I've met some that put their hands over
their ears and said "LA-LA-LA-LA-LA" when I mentioned Raid5 behind
cache.

My assumptions are : For random access, I'm assuming the best thing to
do is to set the stripe size of a RAID volume to the average transfer
size - so if I have, say, 4 disks in a volume they could all in theory
be handling different requests. If I'm doing mostly sequential
transfers, I'm better off setting the stripe size to (number of disks *
transfer size), so a single transfer is spread out amongst as many
disks as possible. Is this correct ?


Strictly, if you are using raid-5 then the discs cannot all be handling
different requests because each request will involve more than one
disc because of the parity.

I was assuming he meant reads, not writes in that example.

Option 1: (the cynic's option) your db is not doing much so the 3510
will more than adequately keep up with it using all the default settings.

Option 2: take the opportunity to experiment with different parameters
before you go live. Probably your db supplier publishes guidelines.
This will have the additional benefit of making you familiar with
the 3510 when a controller fails at 3 o'clock in the morning.

+1 on both. You can reason things out for days and have a quick
benchmark disprove everything....

--
Darren Dunham ddunham@xxxxxxxx
Senior Technical Consultant TAOS http://www.taos.com/
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >
.

Relevant Pages

  • [RFC PATCH 2/2] raid5: use stripe_queues to prioritize the "most deserving" requests
    ... implements a queue in front of the stripe cache. ... As requests are attached, the weight of the ... +static unsigned long queue_weight(unsigned long *bitmap, int disks) ... +static struct stripe_queue * ...
    (Linux-Kernel)
  • RE: Gvinum RAID5 performance
    ... > locks the stripe and serializes access to that stripe only. ... Userland app requests to read in a big chunk of data ... GVinum queues all requests issued to it ...
    (freebsd-current)
  • [PATCH 007 of 13] md: Core of raid5 resize process
    ... Then it finds which stripe heads in the old geometry can provide data ... int non_overwrite = 0; ... * parity, or to satisfy requests ... user-space has requested a sync ...
    (Linux-Kernel)
  • Re: io performance...
    ... If not then I believe the problem you are seeing is that the generic block layer is not performing large enough readahead to keep all the disks in the array reading at once, because the stripe width is rather large. ... I have a sata fakeraid at home of two drives using a stripe factor of 64 KB. ... If I don't issue O_DIRECT IO requests of at least 128 KB, ... To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ ...
    (Linux-Kernel)
  • Re: dd(1) performance when copiing a disk to another (fwd)
    ... First issue: chopping requests. ... But the other issue is alignment. ... Therefore in addition to the size hint, a stripe width and stripe ... The first slice therefore starts in sector number 63. ...
    (freebsd-performance)