InnoDB locks the buffer pool mutex and scans the LRU to remove pages when DROP TABLE is done for a table that uses innodb_file_per_table. If you read the source you might notice that it scans the LRU twice, once in buf_LRU_drop_page_hash_for_tablespace and then again in buf_LRU_invalidate_tablespace. Locking the buffer pool mutex and scanning the LRU isn't cheap when the buffer pool is large. It takes ~1 second on servers I use and that is too much as nothing gets done during that time by other threads.
I changed InnoDB to remove one of the LRU scans and reduced the stall in half. However that was not good enough. The next step was to avoid any LRU scan during DROP TABLE. Several bugs have been filed for this but the primary ones are bug 51325 and bug 64284. To fix bug 51325 InnoDB in trunk and/or MySQL 5.6 has been changed to scan the flush list rather than the LRU. If your server has 10% dirty pages, then the stall should be reduced by a factor of 10. While discussing bug 51325 with the InnoDB engineering team I worked on my version of a fix that avoids scanning either the LRU or the flush list.
I tested the performance of this change by using sysbench with 8 client threads. The test was run in three modes as describe below. The results show that the fix is better at preserving performance during DROP TABLE.
- no drop table - without DROP TABLE running concurrently
- fast drop table - with the fix from the Facebook patch and another connection running DROP TABLE concurrent with queries
- slow drop table -without the fix from the Facebook patch and another connection running DROP TABLE concurrent with queries
PlanetMySQL Voting: Vote UP / Vote DOWN