On Oct 26, 2001 00:03 -0500, Robert Macaulay wrote:
> I realized I didn't include a lvdisplay -v of my volume. Here it is.
> The disks are spread out over 4 scsi busses.
>
> --- Logical volume ---
> LV Name /dev/vgOracle/foo
> VG Name vgOracle
> LV Write Access read/write
> LV Status available
> LV # 52
> # open 0
> LV Size 9.04 GB
> Current LE 2314
> Allocated LE 2314
> Stripes 26
> Stripe size (KByte) 64
> Allocation next free
> Read ahead sectors 120
> Block device 58:51
Well, there was a patch in 2.4.13 to the LVM code to change the readahead
code. First off, it makes the default readahead 1024 sectors (512kB)
which may be the maximum SCSI request size (don't know the details
exactly). It also sets a global read_ahead array, so this may impact
it also. See above, you have a "read ahead" that is smaller than a
single stripe, so it isn't really doing you much good.
However, it is also possible that striping across 26 disks is kind of
pointless, especially for Oracle. You are far better off to do some
intelligent allocation of the disks depending on known usage patterns
(e.g. put tables and their indexes on separate disks, put rollback
files on separate disks, put heavily used tables on their own disks,
put temporary tablespaces on their own disks).
With LVM, you can easily monitor which PVs/PEs are busiest, and even out
the I/O load by moving LVs/PEs with pvmove (although you CANNOT do this
while the database is active).
Make sure you keep backups of your LVM metadata (both vgcfgbackup, and
also save the text output of "pvdata -avP" and "lvdisplay -v").
Cheers, Andreas
--
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert
