Bug #8930 | Heap tables do not free ram after "rename table". | ||
---|---|---|---|
Submitted: | 3 Mar 2005 19:59 | Modified: | 4 May 2005 18:47 |
Reporter: | Jeff C | Email Updates: | |
Status: | Not a Bug | Impact on me: | |
Category: | MySQL Server | Severity: | S1 (Critical) |
Version: | 4.1.10 | OS: | FreeBSD (Freebsd 4.11-RELEASE) |
Assigned to: | CPU Architecture: | Any |
[3 Mar 2005 19:59]
Jeff C
[4 Mar 2005 0:25]
Jeff C
Easier to test... console: perl -le 'while($i++<1000000) { print "x" x 200; }' > /tmp/test.db bug_8930.sql: use test; drop table if exists testing; create table testing (id varchar(200) not null,index(id)) engine=heap; load data infile '/tmp/test.db' ignore into table testing; create table testing2 like testing; alter table testing2 engine=heap; insert ignore into testing2 select * from testing; alter table testing2 engine=heap; rename table testing to testingold, testing2 to testing; drop table testingold; create table testing2 like testing; alter table testing2 engine=heap; insert ignore into testing2 select * from testing; alter table testing2 engine=heap; rename table testing to testingold, testing2 to testing; drop table testingold;
[4 Mar 2005 0:29]
Jeff C
make sure you set max_heap_table_size and use -v -v -v to watch it go on the command line...
[4 May 2005 18:47]
Hartmut Holzgraefe
Once memory has been allocated by a mysqld process (or by a process using malloc() in general) it is never returned to the operating system. It's only freed internaly and may be reused by subsequent malloc() calls. So the actual process size reported by ps or top is the maximum memory ever used by the process, not the current amount of memory actualy being used. As you have two heap tables in parallel until you drop the first one the memory consumption is twice the table size. On doing an ALTER TABLE the table is internally copied so you end up with a short timeframe where you even have three tables existing which explains the max memory use reported by ps being even 3 times as big as the actual table.