Below is the list of changes that have just been committed into a local
4.1 repository of dlenev. When dlenev does a push these changes will
be propagated to the main repository and, within 24 hours after the
push, to the public repository.
For information on how to access the public repository
see http://dev.mysql.com/doc/mysql/en/installing-source-tree.html
ChangeSet@stripped, 2007-03-15 11:30:17+03:00, dlenev@stripped +1 -0
Fix for bug #25966 "2MB per second endless memory consumption after LOCK
TABLE ... WRITE".
CPU hogging occured when connection which had to wait for table lock was
serviced by thread which previously serviced connection that was killed
(note that connections can reuse threads if thread cache is enabled).
One possible scenario which exposed this problem was when thread which
provided binlog dump to replication slave was implicitly/automatically
killed when the same slave reconnected and started pulling data through
different thread/connection.
In 5.* versions memory hogging was added to CPU hogging. Moreover in
those versions the problem also occured when one killed particular query
in connection (using KILL QUERY) and later this connection had to wait for
some table lock.
This problem was caused by the fact that thread-specific mysys_var::abort
variable, which indicates that waiting operations on mysys layer should
be aborted (this includes waiting for table locks), was set by kill
operation but was never reset back. So this value was "inherited" by the
following statements or even other connections (which reused the same
physical thread). Such discrepancy between this variable and THD::killed
flag broke logic on SQL-layer and caused CPU and memory hogging.
This patch tries to fix this problem by properly resetting this member.
There is no test-case associated with this patch since it is hard to test
for memory/CPU hogging conditions in our test-suite.
sql/mysqld.cc@stripped, 2007-03-15 11:30:16+03:00, dlenev@stripped +6 -0
We should not forget to reset THD::mysys_var::abort after kill operation
if we are going to use thread to which this operation was applied for
handling of other connections.
# This is a BitKeeper patch. What follows are the unified diffs for the
# set of deltas contained in the patch. The rest of the patch, the part
# that BitKeeper cares about, is below these diffs.
# User: dlenev
# Host: mockturtle.local
# Root: /home/dlenev/src/mysql-4.1-bg25966
--- 1.627/sql/mysqld.cc 2007-03-15 11:30:21 +03:00
+++ 1.628/sql/mysqld.cc 2007-03-15 11:30:21 +03:00
@@ -1572,6 +1572,12 @@ void end_thread(THD *thd, bool put_in_ca
thd=thread_cache.get();
thd->real_id=pthread_self();
(void) thd->store_globals();
+ /*
+ THD::mysys_var::abort is associated with physical thread rather
+ than with THD object. So we need to reset this flag before using
+ this thread for handling of new THD object/connection.
+ */
+ thd->mysys_var->abort= 0;
thd->thr_create_time= time(NULL);
threads.append(thd);
pthread_mutex_unlock(&LOCK_thread_count);
| Thread |
|---|
| • bk commit into 4.1 tree (dlenev:1.2618) BUG#25966 | dlenev | 15 Mar |