Bug #53045 | LOCK_thread_count locked when per connection threads created | ||
---|---|---|---|
Submitted: | 22 Apr 2010 4:58 | Modified: | 22 Apr 2010 5:34 |
Reporter: | Mark Callaghan | Email Updates: | |
Status: | Verified | Impact on me: | |
Category: | MySQL Server: Locking | Severity: | S5 (Performance) |
Version: | 5.1.45, 5.5 | OS: | Any |
Assigned to: | CPU Architecture: | Any | |
Tags: | create, LOCK_thread_count, thread, thread_cache_size |
[22 Apr 2010 4:58]
Mark Callaghan
[22 Apr 2010 5:34]
MySQL Verification Team
create_new_thread locks LOCK_thread_count. create_thread_to_handle_connection unlocks it after calling pthread_create in the case a cached thread couldn't be found.
[22 Apr 2010 6:12]
James Day
The workaround is to ensure that thread_cache_size is large enough so that it is not common to have to allocate a new thread from the operating system. This is the expected normal way of tuning this variable so it should be a pretty good workaround. This still needs a fix.
[22 Apr 2010 6:26]
James Day
I've asked our documentation team to add this tuning guidance for thread_cache_size, which reflects common practice: "If your server sees hundreds of connections per second you should normally set thread_cache_size so that most new connections use cached threads". There are reasons not to do it, like it being suspected as a cause of a bug or suspected of having a RAM leak in the associated memory allocations. Those aren't common but sometimes it is a suspect.