RE: Odd Slowness in 4.0.5a with binlog
Thanks for your comments! I am not sure why you observe this load (AFAIK, blocked threads should not change the load), but it explains well, why 0 processes are running. They are all waiting. The mysqld segfault with 0 processes does not happen consistently but happens often enough to warrant mentioning. (That is, the slowness of the server and the high load always occur when the binlog disk is full, but the segfault only occurs sometimes when this happens.) When the binlog disk gets full, the queries per second drop to a miserable 500 qps while the load shoots up. I was thinking about your comment about the threads waiting. Maybe they wait for a while, slowing down each query (resulting in more having to be processed simultaneously) which cascades to bring the server to a crawl. There may also be a related issue that sometimes this wait gets stuck (mutex issue?) and then what you described happens. Sincerely, Steven Roussey http://Network54.com/ - 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
Re: Odd Slowness in 4.0.5a with binlog
Hello. On Sat 2002-12-07 at 10:14:57 -0800, [EMAIL PROTECTED] wrote: I have the binlog files stored to a separate drive (actually a partition on a drive other than the raid array for the tables). When this partition becomes full, mysql's load average goes from 1.5 to 25 and stays there until more space is available on the partition that holds the binlog. This isn't the biggest deal in the world, since I should make sure there is enough space, but why is this happening? It never happened with 3.23.x. Although it used to cause a segfault in 4.0.2. (MySQL 4.0.5 actually did segfault, but a while after it ran out of space and had 0 processes running. How it had 0 processes running is beyond me...) Well, the following does not completely describe what you observe, but might be a beginning: When MySQL encounters a disk-full condition, the thread in question complains in the error log, simply sleeps and checks in regular intervals if space has been freed. Soon, there will be another thread which needs to access the same tables/blocks/rows, that the first one did and still may lock, because it did not finish yet. On you go, with one thread after another. Of course, threads which process queries, which do not touch the stuff blocked by the first thread or the binlog itself, will run fine. But as you can imagine, the number of threads blocked will grow with time and the number of threads to do other stuff will decrease until all threads are blocked. I am not sure why you observe this load (AFAIK, blocked threads should not change the load), but it explains well, why 0 processes are running. They are all waiting. HTH, Benjamin. PS: Of course, that was only a general description. In real, details may be more complex. For example, I could bet that writing on the binlog is protected by a mutex. Therefore only the first thread waits due to the disk full condition. Others which want to write to binlog are waiting on the mutex instead. But anyhow, you get the idea. -- [EMAIL PROTECTED] - 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
Odd Slowness in 4.0.5a with binlog
I have the binlog files stored to a separate drive (actually a partition on a drive other than the raid array for the tables). When this partition becomes full, mysql's load average goes from 1.5 to 25 and stays there until more space is available on the partition that holds the binlog. This isn't the biggest deal in the world, since I should make sure there is enough space, but why is this happening? It never happened with 3.23.x. Although it used to cause a segfault in 4.0.2. (MySQL 4.0.5 actually did segfault, but a while after it ran out of space and had 0 processes running. How it had 0 processes running is beyond me...) Sincerely, Steven Roussey http://Network54.com/ sql,query - 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
