Hi Cristiana, I am another FreeBSD user and I can tell you that FreeBSD 4.1.1 does have problems with threads. I would very much recommend that you update as there are also many security problems with that version if you are running a server that is remotely available. There were many threads problems fixed in 4.3, the current version is 4.6.
Also this list is for the internal programming of how mysql works. Please use [EMAIL PROTECTED] for questions that do not concern the internal programming of MySQL. I copied this response to the main mailing list. There is a really good tutorial on updating FreeBSD at http://www.mostgraveconcern.com/freebsd/ See http://www.mostgraveconcern.com/freebsd/cvsup.html Good luck, Ken ----- Original Message ----- From: "Cristiana Amza" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, September 27, 2002 11:27 AM Subject: MySQL overload problem ? > > Hi. > > We have been using MySQL for a couple of years as a back-end for a dynamic > content server. We are using it in a research setting, so we are generally > not averse to changing the MySQL code if necessary. > This message, however is intended only to better understand its inner workings. > > We see the following behaviour that we cannot really explain. > > We have a workload where several clients are concurrently > issuing moderate-to-heavy-weight queries to MySQL. > In particular, there is a query that takes about 700 msec if run alone. > If a low number of clients (e.g. 4-5!) execute this query concurrently > throughput degrades (to a value lower than if these queries were run > sequentially). > > The query is a (SELECT) 3-table join, and has an order by and group by > clause (and limit 50). > The query accesses a small amount of data and is CPU bound > (there is little disk activity with warm caches). > Other (INSERT/UPDATE) queries may run concurrently on the accessed tables, > but the problem appears even if there are none. > The key point is - with very few concurrent clients, performance degrades > quite rapidly, and we need to limit the total load (in terms of total > execution time of queries outstanding at MySQL, not number of clients/queries). > > We are not using the MySQL query cache. > Table cache settings are standard. > > This points to a very high context-switching overhead. > We have read in the documentation that this may be due to the thread > library overhead because threads may "acquire/release a mutex over a > short critical region frequently". > We are using FreeBSD 4.1.1 thus user-level threads, can't imagine that context > switching itself between (5!) threads could be that expensive, unless it is > for some reason very very frequent. > Can you please elaborate on exactly the sequence of operations that MySQL > does that would produce this behaviour (possibly coupled with the threading > library's actions). > > We thank you in advance for shedding light on this. The problem has > plagued us for some time. > > -Cristiana > > -------------------------------------------------------------------- - > 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]> > > --------------------------------------------------------------------- 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
