This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [libc-alpha] Mysql and their patches to LinuxThread


On Sunday 09 December 2001 05:45 pm, Michael Widenius wrote:
> The reason for making the stack smaller by default was that the user
> definable stacks didn't work when Sasha tested it.
> 
> Sasha, can you comment on this !

The problem with user-defined stacks is that ( at least last time I checked), 
this had to be set at compile time. This means that if the user links against 
default LinuxThreads, he does not get the feature in most cases, so we are 
stuck with the 2MB spacing. If user-defined stacks could be enabled at run 
time, this part of the patch would not be needed.


> 
> I agree that normally one want big stacks, but in our case the above
> was the best option.
> 
> Kaz> The library should be the last place to do MySQL-specific 
optimizations;
> Kaz> by doing that you are saying that there is no work left to be done
> Kaz> in the application, because it does everything perfectly. When I hear
> Kaz> about large numbers of connections requiring large numbers of threads,
> Kaz> I don't exactly have that impression. ?Why is that the case? Is a new
> Kaz> thread dedicated to each new connection?
> 
> Yes, MySQL uses a dedicated thread per connection.
> In practice this has worked very good for us for over 2000
> connections without a patched library and > 4000 for patched
> libraries.

Monty must have been tired when he wrote the above paragraph - he works long 
hours. If you do not patch the thread library, you cannot have more than 1021 
connections since you can have only 1024 threads, and first 3 are taken for 
internal purposes at the start.

MySQL will work ok without patching the thread library for about 300-400 
connections. After that, at some point, depending on internal memory usage, 
you start running into the problem of stack stealing pages from the heap. 
Adjusting the thread stack spacing allows MySQL to be quite stable and fast 
with 2000 connections ( tested). What happens after that I do not know - 
never had a machine with enough RAM to try it.

So up to this point, we have not had very much insentive to optimize the 
total number of threads needed to handle a large number of connections. We 
might do it in the future at some point. But for now, we are quite satisfied 
with providing a simple patch for LinuxThreads for those who really want to 
compile themeselves, and statically linking the binary we distribute against 
a patched library.
 
-- 
MySQL Development Team
For technical support contracts, visit https://order.mysql.com/
   __  ___     ___ ____  __ 
  /  |/  /_ __/ __/ __ \/ /   Sasha Pachev <sasha@mysql.com>
 / /|_/ / // /\ \/ /_/ / /__  MySQL AB, http://www.mysql.com/
/_/  /_/\_, /___/\___\_\___/  Provo, Utah, USA
       <___/                  


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]