One thing that makes me think I am doing something wrong is that if I build the indexes on a 60MB file, it still takes a considerable amount of time (6-8 min/index) and there is still a considerable amount of (almost continuous) disk activity. I find that curious because the 60MB file fits completely in cache...at multiple levels: OS and DB. So one would anticipate that the disk activity was due to writes? Shouldn't the database build large chunks of the index and write it back in increments? I would hope that "chunk" would be in the 64MB range...hence one big read, one ram-based index, one big write. This is not the case.
Is atime being updated continuously? I'll mount with noatime and try it again, though I suspect it is something else. I forgot to mention file system is ext2.
bbaker
On Mon, Nov 03, 2003 at 11:18:55AM -0600, William Baker wrote:
I am using a pentium4-2GHz machine with Linux-RH9 installed and 1GB RAM. The database is on a dedicated SCSI drive with an Adaptec UltraScsi3 controller which shows 40MHz bus connecting the 10K-RPM disks. (Fairly new, fairly capable, low-end server grade.)
I have a 2GB datafile with 10 indexes. Each of those indexes takes about 1.5 hrs to build (total of 15 hours). Any suggestions for reducing build time ... preferrably to around 10 minutes or less? I could even live with 20 minutes for each. (Our current system uses ISAM style indexed data files.
Without understanding the bottleneck, that's a difficult question to answer. Is it CPU bound? Disk I/O bound?
Jeremy
-- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
