1
0
mirror of https://github.com/MariaDB/server.git synced 2025-07-27 18:02:13 +03:00

Bug#21074 Large query_cache freezes mysql server sporadically under heavy load

Invaldating a subset of a sufficiently large query cache can take a long time.
During this time the server is efficiently frozen and no other operation can
be executed. This patch addresses this problem by moving the locks which cause
the freezing and also by temporarily disable the query cache while the 
invalidation takes place.


sql/ha_ndbcluster.cc:
  - mysql_rm_table_part2 has a new parameter to indicate if OPEN_lock mutex 
    protection is needed.
sql/lock.cc:
  - Added function for acquiring table name exclusive locks.
  - Added function for asserting that table name lock is acquired.
sql/mysql_priv.h:
  - Added function for acquiring table name exclusive locks.
  - Added function for asserting that table name lock is acquired.
  - Added parameter to mysql_rm_table_part2 to indicate whether OPEN_lock mutex
    protection is needed or not.
sql/sql_cache.cc:
  - Changed flush_in_progress-flag into a state and added a function, 
    is_flushing() to reflect on this state. A new state was needed to indicate
    that a partial invalidation was in progress.
  - An unused parameter 'under_guard' was removed.
  - The Query_cache mutex structural_guard was pushed down into one
    invalidate_table function to avoid multiple entry points which makes
    maintainens more difficult.
  - Instead of keeping the structural_guard mutex during the entire invalidation
    we set the query cache status state to TABLE_FLUSH_IN_PROGRESS to
    temporarily disable the cache and avoid locking other threads needing the
    Query_cache resource.
sql/sql_cache.h:
  - Changed flush_in_progress-flag into a state and added a function, 
    is_flushing() to reflect on this state. A new state was needed to indicate
    that a partial invalidation was in progress.
  - An unused parameter 'under_guard' was removed.
  - The Query_cache mutex structural_guard was pushed down into one
    invalidate_table function to avoid multiple entry points which makes
    maintainens more difficult.
  - Instead of keeping the structural_guard mutex during the entire invalidation
    we set the query cache status state to TABLE_FLUSH_IN_PROGRESS to
    temporarily disable the cache and avoid locking other threads needing the
    the Query_cache resource.
sql/sql_db.cc:
  - mysql_rm_table_part2_with_lock is redundant and replaced
  with mysql_rm_table_part2.
sql/sql_parse.cc:
  - Function query_cache_invalidate3 isn't protect by a lock and we have a 
    race condition.
  - Moving this function into mysql_rename_tables and make sure it is protected
    by a exclusive table name lock.
sql/sql_rename.cc:
  - Function query_cache_invalidation3 isn't protect by a lock and we have a 
    race condition.
  - Moving this function into mysql_rename_tables and make sure it is protected
    by a exclusive table name lock.
  - Instead of using LOCK_open mutex, which excludes all other threads, the lock
    is changed into exclusive table name locks instead. This prevents us from
    locking the server if a query cache invalidation would take a long time to
    complete.
sql/sql_table.cc:
  - Instead of using LOCK_open mutex, which excludes all other threads, the lock
    is changed into exclusive table name locks instead. This prevents us from
    locking the server if a query cache invalidation would take a long time to
    complete.
  - Added new parameter to mysql_rm_table_part2 to control whether OPEN_lock mutex
    needs to be aquired or not. This is currently needed by the NDB implemenation.
sql/sql_trigger.cc:
  - Table_triggers don't need to be protexted by LOCK_open mutex. This 
    patch cancel this restriction.
  - Refactored comments to doxygen style.
This commit is contained in:
unknown
2007-07-02 19:14:48 +02:00
parent 0484d44eeb
commit 289cc26c64
10 changed files with 677 additions and 372 deletions

File diff suppressed because it is too large Load Diff