Date: Sun, 21 Jan 2001 20:09:07 -0600 From: Dan Nelson <dnelson@emsphone.com> To: Noor Dawod <noor@comrax.com> Cc: freebsd-questions@FreeBSD.ORG Subject: Re: Unexplained high-loads on FreeBSD Message-ID: <20010121200907.A2542@dan.emsphone.com> In-Reply-To: <PHEBIOJOBJJLIIJCOINKIELODCAA.noor@comrax.com>; from "Noor Dawod" on Sun Jan 21 17:07:26 GMT 2001 References: <PHEBIOJOBJJLIIJCOINKIELODCAA.noor@comrax.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In the last episode (Jan 21), Noor Dawod said: > The problem persists, though, and here it is: every once in a while, > sometimes once a week, the mysqld process goes into OVERHEAT state > with CPU usage getting as high as 97%, thus making it almost > impossible for clients to connect to it. I checked mysqld's process > usage once while this happened, and I found around 60 processes > (connections). Not a big deal as I saw much more processes connect to > the same daemon before, and still it continued to work. Your high CPU usage is probably due to a complex query. Add "log-slow-queries" to the [mysqld] section of your my.cnf, restart mysql, and check slow.log after one of your high-load periods. Analyze any queries that show up and add indexes as needed. Also check the output of "show status" before and after, keeping an eye on Created_tmp_tables, Handler_read_rnd, Handler_read_rnd_next, Key_reads, and Sort_merge_passes. See the manual for details. > I'm attaching the my.cnf file for you to examine. Remember, this is > the stock my.cnf file that came with MySQL for large Web sites (those > having more than 512MB of memory), with a little modification. Try raising sort_buffer and tmp_table_size to 16M at least. This will help if you truly have a complex query that has to run through a lot of records. > By the way, someone on the MySQL mailing list suggested that BSD's > threading support "sucks", and only after he moved to Debian that > these simptoms disappeared. FreeBSD's threads are currently user-level and all threads block when one does disk I/O. This is sort of a worst-case scenario for a disk-intensive app like a database, but with enough memory you shouldn't really be hitting the disk that often anyway. -- Dan Nelson dnelson@emsphone.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010121200907.A2542>