Whenever any maintenance needs server restarts, there’s a list of unsolved bottlenecks or inefficient code that gets touched a lot at that time. I can understand that heating up the server can take lots of time (though lots of low hanging fruits there), but the way actual shutdown is done, even if there’s not much of dirty data to flush, sucks.
See, developers are perfectionists, and their perfectionism also includes the crazy idea that all memory has to be deallocated at server shutdown, as otherwise Valgrind and other tools will complain that someone leaked memory. Developers will write expensive code in shutdown routines that will traverse every memory structure and deallocate/free() it.
Now, guess what would happen if they wouldn’t write all this expensive memory deallocation code.
Still guessing?
OS would do it for them, much much much faster, without blocking the shutdown for minutes or using excessive amounts of CPU. \o/
domas mituzas 
… making it impossible to find any memory leaks \o/ … really ?
Jan, feel free to put if(reallyreallycleanup) for your memleak finding code ;-)
I agree that complicated cleanup is a bad idea. And that people write this code to just please tools that find false positives also does not sound good.
I think you are aiming at the wrong direction. If developers structured things in a proper way (eg, memory root), traversing should be minimal. Also, the kernel has to do this too, freeing memory is not that simple and can cause severe latency. Nonetheless, this is not about perfection, its about consistency (and special cases for tools are not welcome). There is also a reason why this must be done in mysql in some cases: embedded.
yes, flushing the whole heap is much cheaper than every variable one by one.
That is strong side of erlang (for instance), where each thread has it’s own heap. when the thread ends, erlang flushes the the whole heap of that thread.
In some cases I agree with you, Domas. Memory allocated in static space (like some of the InnoDB data dictionary, nss lookup stuff, pcre state, etc, can be a little over-the-top to manually free at shutdown.
However, there are certain circumstances where the *order* of de-allocation makes a difference. For instance, in Drizzle, shutting down global heap-allocated stuff before calling each plugin’s destructor would be, well, not a good idea :) So, I partly agree and partly disagree. :) When in doubt, I always prefer explicit over implicit.
Cheers!
Jay
Yes I had a similar but worse problem with a SQL database, it was taking too long to perform a query then when told to stop tried to roll-back the query. Even re-starting the database mean it tried to do hours of cleanup before letting a humble user in to drop the tables. The quickest solution was to delete and rebuild the (effectively) empty database. And it was trying to be user friendly.