OK, I'll qualify the statement. Software RAID-5 on my adaptec SCSI controller and external disk array logs a message "aic7xxx_abort returns 0x2003" to /var/log/messages and the whole array shuts down (and anything else attached to the card, regardless of bus) for minutes at a time before restarting without any intervention. Google searches suggest that this configuration worked reliably before kernel 2.4.4 and may be related to lost interrups when sharing an IRQ. (My controller is sharing and IRQ with the ethernet card. Buggy ethernet driver disabling interrupts could cause this behavior.) Both 2.4.20 and 2.6.0-test9 failed with the same errors. Some people had success using "noapic". Not me. So, I have given up on my software raid configuration for now because it is unstable. I'll get back to it when database issues have been solved.

Is that better?

On Fri, Nov 07, 2003 at 05:03:43PM -0600, William Baker wrote:


Sorry for the slow reply. I was battling SCSI controller bugs as well as database issues. I have given up on the software raid for now because it is unstable.



Really? I've run Linux software RAID quite happily on several systems (both RAID-5 and RAID-1) for years.



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.



Ah, good.




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.



Did we already talk about the log flush method you're using with InnoDB? I don't recall...

Jeremy





-- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]



Reply via email to