Perhaps the physical layout of your disk drives are contributing to the
'slowness'...
- Are the 12 drives making up the SCSI RAID 5 array the only drives in the
system ?
- Do you have the O/S and/or the 'temp' area being used by MySQL on
different drive devices than the RAID array ? (is the 'temp' area a 'RAID
5' partition ?)
- How many SPARC CPU's (and what 'speed') are installed in the system ?
- What are the 'size' of the disk drives ? Are they all identical drive
models ?
- How many Symbios SCSI controller cards (besides the initial 'onboard'
controller) are installed in the system ?
If you are reading, and writing, the data to and from the same 12 drives
that make up the RAID 5 array, you would see an I/O bottlekneck (though,
with 4 gigabytes of RAM, it should be able to 'buffer' a lot of the I/O
transactions). Not only is 'writing' to RAID 5 arrays slow, the more
devices (above 8) used in a RAID-5 array, the longer it takes for all
drives to 'respond' to any SCSI commands (and I doubt that the 'block' or
'data segment' reads/writes are spread across all 12 drives). AND, if you
originally created the RAID array with less drives, and have been
'extending' it, the 'parity' sectors would only be located on the original
drives in the array, which take the 'brunt' of the parity calculation
'writes'...
The Sun E450 is capable of having a total of 5 SCSI controller 'paths'
(visibly seen as 5 SCSI cables) when 2 additional Symbios 'dual path' SCSI
controllers are installed. Though the system can hold a total of 20 disk
drives, it's very limited to how they can be arranged for performance and
availability (see the crude chart below).
The only efficient (and safe) manner of drive installation and configuration
in an E450, is to create 5 drive 'arrays' using disks that are installed on
each of the 'paths'. This allows concurrent controller access and spreads
the 'bandwidth' over all 5. And, if 1 controller 'chip' fails, the RAID
remains intact (though if an entire Symbios 'card' fails, you'd lose 2
paths/drives and the data as well).
If your table(s) have grown larger than a 5 drive array (when if 'raided'
would only equal 4 drives in disk space), you'd have to 'break' the method
described above, or use MySQL's ability to 'stripe' the database across
different partitions.
If you can fit individual tables within the 5 drive arrays, have you
considered locating the different tables on separate arrays ??
Sun E450 drive bay configuration:
Drive slots
18 19
16 17
SCSI Controller 3 & 4 <
14 15
12 13
10 11
8 9
SCSI Controller 1 & 2 <
6 7
4 5
SCSI controller 0 (on-board chip) 2 3
0 1
Preferred drive configuration:
O/S (Solaris partitions) - mirrored on drives 0 & 1
Data - RAID 5 array on drives 2, 6, 10, 14, 18
Data - RAID 5 array on drives 3, 7, 11, 15, 19
Indexes - Mirrored drives 4 & 12, 8 & 16 (note: each 'half' of the
mirror is located on a different SCSI 'card' as well as 'path', to protect
against an entire 'card' failing)
Temp - Mirrored drives 5 & 13
----- Original Message -----
Sent: Thursday, May 31, 2001 8:55 AM
Subject: Re: myisamchk --sort-records extremely slow
> In the last episode (May 30), Michael Villalba said:
> > I have a rather large MyISAM table (~230 million rows) running under
> > MySQL 3.23.30. It has 10 columns and 3 indices. The data and index
> > files each occupy about 10GB.
> >
> > My problem is that sorting the rows using myisamchk --sort-records
> > takes an extremely long time. The last sort took 95 hours (that's
> > right...almost four days).
> >
> > The machine is a four-processor Sun E450 with 4GB of memory. The OS
> > is Solaris 2.7. The database files reside on a 12-disk SCSI RAID 5
> > array. The machine was essentially idle with the exception of the
> > sort job.
---------------------------------------------------------------------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php