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

[Michael Widenius <monty at mysql dot com>]

Hi!

>>>>> "Kaz" == Kaz Kylheku <kaz@ashi.footprints.net> writes:

Kaz> On Mon, 3 Dec 2001, Yusuf Goolamabbas wrote:
>> Date: Mon, 3 Dec 2001 13:18:09 +0800
>> From: Yusuf Goolamabbas <yusufg@outblaze.com>
>> To: libc-alpha@sources.redhat.com
>> Cc: monty@mysql.com, sascha@mysql.com
>> Subject: [libc-alpha] Mysql and their patches to LinuxThread
>> 
>> Hi, I came across this web page at mysql.com which suggests that
>> Linuxthreads be patched in a certain way for mysql to be optimal in
>> performance under high load
>> 
>> http://www.mysql.com/doc/L/i/Linux.html
>> 
>> http://www.mysql.com/Downloads/Linux/linuxthreads-2.2.2.patch

Kaz> The MAX_ADAPTIVE_SPIN_COUNT part of the patch is already in CVS. I
Kaz> think 100 is a little low, by the way.

Good!

As one should only use spin locks for segments that one 'knows' will be
locked for a very short time, 100 should not be a bad value.
At least this value seams to work very good for MySQL :)

Kaz> As far as making the stacks smaller so you can cram more threads into
Kaz> the address space; I don't agree with this at all.

Kaz> A 128 kilobyte stack is risky; you never know when someone is going
Kaz> to do some deep recursion or use variable length arrays or alloca()
Kaz> or whatever.  UNIX programmers are accustomed to abusing stacks, which
Kaz> likely carries over into threaded programming.  There may be programs
Kaz> out there which depend on the 2 megabyte stack space that LinuxThreads
Kaz> provides; you can't just suddenly sneak in a change that shrinks the
Kaz> stack by a factor of 16.

Kaz> If you want user-defined stacks, the support is there.

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 !

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.

We could of course also use a thread pool to avoid many connections,
but we would get a lot of other problems instead that we have already
solved in the current MySQL version.

(At some point we plan to make this configurable when compiling MySQL...)

Regards,
Monty