innodb_file_per_table and DROP TABLE after OSC

MySQL & MariaDB Other MySQL® Questions
1

Even with innodb_lazy_drop_table ON, we’re still seeing issues around DROP TABLE performance (version 5.5.28-29.1-log Percona Server). During an overnight maintenance, it took 9 minutes to drop an empty table (the table had been around 9.5GB in size, but had been cleared of all its data during an archive/delete before the drop, so had 0 rows).

I’ve seen a couple of bug reports (things like [URL=“http://MySQL Bugs: #51325: Dropping an empty innodb table takes a long time with large buffer pool”]MySQL Bugs: #51325: Dropping an empty innodb table takes a long time with large buffer pool and [URL]MySQL Bugs: #64284: Eliminate LRU scan when dropping a table) but those are marked as closed with fixes as far back as 5.5.13 and 5.5.23, however the issue doesn’t seem to be any different for us over the entire 5.5 branch. Is there currently any known way to alleviate these issues? We perform quite a lot of online schema changes to large tables, and need to be able to drop these tables from the master without downtime to reclaim space.

2

What filesystem do you use? Note that for example ext3 is very bad at removing big files.

Also here you can find very detailed approach to the problem:
http://www.mysqlperformanceblog.com/2012/06/22/drop-table-an d-stalls-lazy-drop-table-in-percona-server-and-the-new-fixes -in-mysql/

3

We do use ext3 yes, and although its delete file performance is pretty miserable, it still doesn’t take 9 minutes to delete a 9.5GB file.

The lazy drop table blog post seems to indicate that dropping tables lowers the performance of the database during the drop, but what we’re seeing is a complete locking of all queries during the time the drop is being performed, and nothing can run on the server, and I was more wondering whether there were any improvements that were due in the 5.5 branch, or likely to appear in 5.6, that would significantly alleviate this.