Re: [linux-lvm] More information on my LV with bad read performance..

[Andreas Dilger <adilger@turbolabs.com>]

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