| Bug #59316 | Partitioning and index_merge memory leak | ||
|---|---|---|---|
| Submitted: | 5 Jan 2011 20:37 | Modified: | 26 Apr 2011 14:08 |
| Reporter: | Shannon Wade | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: Partitions | Severity: | S2 (Serious) |
| Version: | 5.1.50, 5.5.8 | OS: | Linux |
| Assigned to: | Mattias Jonsson | CPU Architecture: | Any |
| Tags: | Leak, memory leak | ||
[5 Jan 2011 20:37]
Shannon Wade
[6 Jan 2011 5:06]
MySQL Verification Team
how about using a memory profiler to check what uses the memory? http://goog-perftools.sourceforge.net/doc/heap_profiler.html
[11 Jan 2011 20:53]
MySQL Verification Team
using libtcmalloc and a 10G buffer pool, pprof output is:
Total: 2582.2 MB
2028.1 78.5% 78.5% 2028.1 78.5% my_malloc
499.7 19.4% 97.9% 499.7 19.4% ut_malloc_low
47.8 1.8% 99.7% 47.8 1.8% mem_area_alloc
6.4 0.2% 100.0% 6.4 0.2% my_realloc
0.1 0.0% 100.0% 0.1 0.0% my_once_alloc
0.0 0.0% 100.0% 0.0 0.0% __new_exitfn
0.0 0.0% 100.0% 0.0 0.0% init_slave
0.0 0.0% 100.0% 0.0 0.0% _dl_allocate_tls
0.0 0.0% 100.0% 0.0 0.0% fdopen@@GLIBC_2.2.5
0.0 0.0% 100.0% 0.0 0.0% LOGGER::init_base
0.0 0.0% 100.0% 0.0 0.0% __tzfile_read
0.0 0.0% 100.0% 0.0 0.0% MDL_lock (inline)
0.0 0.0% 100.0% 0.0 0.0% my_thread_init
0.0 0.0% 100.0% 0.0 0.0% my_regex_init
0.0 0.0% 100.0% 0.1 0.0% init_common_variables
0.0 0.0% 100.0% 0.0 0.0% MDL_lock::create (inline)
0.0 0.0% 100.0% 0.0 0.0% get_quick_select
0.0 0.0% 100.0% 0.0 0.0% Events::init
0.0 0.0% 100.0% 0.1 0.0% acl_init
0.0 0.0% 100.0% 0.0 0.0% hostname_cache_init
<snip> rest as it's all 0.0
[24 Jan 2011 15:48]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/129458 3271 Mattias Jonsson 2011-01-24 Bug#59316: Partitioning and index_merge memory leak When executing row-ordered-retrieval index merge, the handler was cloned, but it used the wrong memory root, so instead of allocating memory on the thread/query's mem_root, it used the table's mem_root, resulting in non released memory in the table object, and was not freed until the table was closed. Solution was to ensure that memory used during cloning of a handler was allocated from the correct memory root. @ sql/ha_partition.cc Created a new ha_partition constructor for use when cloning. Also set the partitions handlers to be clones of the original tables partitions. Moved code from get_from_handler_file to a new function read_handler_file. @ sql/ha_partition.h Moved is_clone variable to handler.h. Added helper function get_handler_for_partition. @ sql/handler.cc Moved allocation of ref to ha_open, also for clones. @ sql/handler.h Added is_clone_of and clone_mem_root. For more generic handling of clones @ storage/heap/ha_heap.cc Removed ha_heap::clone(), using handler::clone() instead. Moved clone specific code to ::open() instead. @ storage/heap/ha_heap.h Removed clone, added helper function hp_info(). @ storage/myisam/ha_myisam.cc Removed clone(), using handler::clone() instead. Moved clone specific code to ::open() instead. @ storage/myisam/ha_myisam.h removed clone(). @ storage/myisammrg/ha_myisammrg.cc Moved is_cloned variable to handler::is_clone_of. Removed ::clone(). Moved clone specific code to ::open(). @ storage/myisammrg/ha_myisammrg.h Moved is_cloned to handler::is_clone_of. removed ::clone(), using handler::clone instead.
[24 Jan 2011 17:12]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/129472 3565 Mattias Jonsson 2011-01-24 Bug#59316: Partitioning and index_merge memory leak Backport of patch from 5.5 to 5.1.
[24 Jan 2011 18:03]
Mattias Jonsson
Note that there are no tests included, we need someway to monitor allocated memory, preferable per table/handler/thread etc. to support tests for this kind of bug. A similar mem leak was bug#27732. Would be good if something like bug#43237 was implemented (or similar in Performance_Schema). I have verified the fix in both 5.1 and 5.5 by monitoring the mysqld process, as well as using heap profile (from google-perftools).
[5 Apr 2011 21:43]
James Day
The workaround for this is: set global optimizer_switch='index_merge=off' You can try to prove it's the cause using FLUSH TBLES but that might not have a visible effect sometimes.
[26 Apr 2011 14:08]
Jon Stephens
Documented bugfix in the 5.1.58, 5.5.13, and 5.6.3 changelogs, as follows:
When executing a row-ordered retrieval index merge,
the partitioning handler used memory from from that allocated
for the table, rather than that allocated to the query, causing
table object memory not to be freed until the table was closed.
Closed.
[11 Jul 2011 14:38]
Thomas Parrott
Hi, I am seeing increasing memory usage with MySQL server when using partitioned tables, it keeps growing well beyond the limits of the innodb_buffer_pool setting. I am running 5.5.14 on x86_64 CentOS 5.6
[12 Jul 2011 18:20]
MySQL Verification Team
Thomas, Try: optimizer_switch=index_merge=off In the my.cnf, restart mysqld see if memory usage increases. Likely it is the result of something else and not related to this bug. Next when mysqld memory usage is provide: mysql> SELECT SUM(DATA_LENGTH+INDEX_LENGTH) FROM INFORMATION_SCHEMA.TABLES WHERE ENGINE='MEMORY'; Then run: mysql> flush hosts; mysql> flush logs; mysql> flush query cache; mysql> flush privileges; mysql> flush status; mysql> flush tables; And make sure memory isn't free'd. Then when mysqld memory is unusually high post my.cnf and output from OS of: shell> top -b -n 1 shell> free -m
[12 Sep 2011 23:32]
Ryan Hendrickson
RedHat 4 update 8.. x86_64 MySQL 5.5.15 I'm seeing the anon's grow size type count 27816 other 55 21980520 anon 14,284 total size: 22008336 When I say "Other" as a type above: I mean the libraries, mysqld, and any item other than the anon's. The anon's appear to grow my virtual memory size, and eventually I assume they consume my resident memory as it is growing very large as well. mysqld is now at 21G virtual and 15G resident. Ryan
