Back to the subject at hand: performance.
You are right, the "load" is meaningless outside the context of a specific machine...and often even inside the context of a specific machine. top showed that the system was disk (iowait) bound. Changing the innodb_log_buffer_size (64MB) and innodb_log_file_size (32MB) was the trick to increasing performance significantly. I was able to cut index build time in half.
There is still way too much disk activity during the index build. Since the whole file fits in cache at several levels, it makes no sense that the CPU still reflects an average of >20% in iowait. At least user space is now around 70% cpu usage, which is up from under 50%. Other than digging into souce code and using strace, I'm clueless as to how to improve this situation. I think it's still way too high. I've tried variations of all the system variables that appear to be relevant.
bbaker
On Mon, Nov 03, 2003 at 01:35:26PM -0600, William Baker wrote:
It's hard to tell. The CPU is under a reasonable load (uptime shows 1.0 - 2.0), no swapping, and the hard drive is churning away continually.
The "load average" is relatively meaningless. What's the actualy CPU utilization as shown by top, vmstat, or similar tools?
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.
That could be, but it should affect things much either.
Jeremy
-- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
