SPEEDING UP SHUTDOWN / STARTUP

Since you are dealing with the InnoDB Storage Engine, you need to think about what MySQL does during a startup and during a shutdown.

During a shutdown, InnoDB tends to freeze everything in terms of transactions Dirty pages in the InnoDB Buffer Pool are flushed. During a startup, InnoDB crash recovery rolls forward any leftover changes in the transaction logs. The InnoDB Double Write Buffer may also be scanned during InnoDB crash recovery.

The first variable I think you should set innodb_fast_shutdown to 0.

Please note the MySQL Documentation:

The InnoDB shutdown mode. If the value is 0, InnoDB does a slow shutdown, a full purge and an insert buffer merge before shutting down. If the value is 1 (the default), InnoDB skips these operations at shutdown, a process known as a fast shutdown. If the value is 2, InnoDB flushes its logs and shuts down cold, as if MySQL had crashed; no committed transactions are lost, but the crash recovery operation makes the next startup take longer.

The slow shutdown can take minutes, or even hours in extreme cases where substantial amounts of data are still buffered. Use the slow shutdown technique before upgrading or downgrading between MySQL major releases, so that all data files are fully prepared in case the upgrade process updates the file format.

Use innodb_fast_shutdown=2 in emergency or troubleshooting situations, to get the absolute fastest shutdown if data is at risk of corruption.

OK that takes care of a faster startup. The tradeoff is longer shutdown.

Is there anything you can do speed up a shutdown ? Yes !!!

Get dirty pages from the InnoDB Buffer Pool written to disk more frequently. How ?

You need to set innodb_max_dirty_pages_pct = 0. By doing this, the shutdown process takes less time to flush dirty pages to the .ibd files.

Is there anything else to help startup ? Yes, there is one more.

When you startup mysql, usually the InnoDB Buffer Pool is empty after its allocation.

You could make mysql save the block numbers of all 16KB pages that were in the the buffer pool. Just add innodb_buffer_pool_load_at_startup and innodb_buffer_pool_dump_at_shutdown. This will not time a long time since it writes block numbers to a binary files, not the blocks themselves.

LARGER NUMBER OF FILES

InnoDB's default for open files (innodb_open_files) is 300 for MySQL 5.5. For MySQL 5.6, the ideal number is set for you. You may need to increase this value as well. InnoDB may cache the open files once you reach this limit.

You may have to compensate by raising the value to 100000 or 200000. You could also increase the ULIMIT in the OS to allow MySQL to have more file handles and set open_files_limit to that max value.

I would further suggest increasing RAM in the DB Server.

SUMMARY

Here are the options you need to add

[mysqld]
innodb_fast_shutdown=0
innodb_max_dirty_pages_pct=0
innodb_buffer_pool_load_at_startup=1
innodb_buffer_pool_dump_at_shutdown=1
innodb_open_files=(much higher value)
open_files_limit=(much higher value)

Depending on the environment, you may not need all four options. Perhaps setting innodb_fast_shutdown to 2 is better than 0. Maybe the default setting for innodb_max_dirty_pages_pct is fine if you have low-write activity. In any case, test which options help your shutdown and startup concerns.

Keep in mind that innodb_buffer_pool_load_at_startup and innodb_buffer_pool_dump_at_shutdown are for MySQL 5.6. Therefore, check to see if the version of Percona Server you are using has those two options.

Give it a Try !!!

Yes, this is normal. Linux will use any free memory if needed for cache and buffers - it will be reallocated if needed for anything else (i.e. stating a new program, an existing program needing more memory for something, caching more recently accessed information, or the hypervisor requesting some memory back by inflating the local balloon if you VM is setup that way, and so on).

This is all managed automatically, but if you really want to fully clear it yourself you can by running sync; echo 3 > /proc/sys/vm/drop_caches as root. The only reason I can think of for doing that is if you are running performance tests and want a repeatable "from cold" starting point without completely restarting.

If mysql is using memory mapped files for accessing its data files (which is likely as there can be performance benefits to this method) then any block currently loaded from them will show up as cached data, so as well as the 250Mb input file your ~3G of cache will include things already in memory counted in the "cached" figure before you started, the data and index blocks created as a result of the import, and any related blocks that needed to be read as part of the process.