The perils of InnoDB with Debian and startup scripts

Are you running MySQL on Debian or Ubuntu with InnoDB? You might want to disable /etc/mysql/debian-start. When you run /etc/init.d/mysql start it runs this script, which runs mysqlcheck, which can destroy performance.

It can happen on a server with MyISAM tables, if there are enough tables, but it is far worse on InnoDB. There are a few reasons why this happens — access to open an InnoDB table is serialized by a mutex, for one thing, and the mysqlcheck script opens all tables. One at a time.

It’s pretty easy to get into a “perfect storm” scenario. For example, I’m working with one client right now who has a hosted multi-tenanting application that keeps each customer in its own database. So they have a lot of databases and a lot of tables. And they’re running on Amazon EC2 with 8G of RAM and EBS storage, which is slower than typical directly-attached server-grade RAID storage. Since they have a lot of tables, InnoDB uses over 3.5G of memory for its data dictionary (the subject for another post — we’re working on a fix) and so we can’t make the buffer pool as large as we’d like to.

To avoid physical I/O all the time we need to get some reasonable amount of data into the buffer pool. But we have to do this without death-by-swapping, which would be extremely slow on this machine, so we need to stop the buffer pool and the OS cache from competing. My chosen strategy for this was to set innodb_flush_method=O_DIRECT. We could also tune the OS, but in my experience that’s not as effective when you’re really pushing to get memory into the buffer pool. Remember we have 3.5G of memory less to play with, solely due to the data dictionary.

But this strategy will only reduce physical reads if the buffer pool follows a typical access pattern. That is, some of the data is in your working set and will stay in the buffer pool, some small part of it will move in and out of the buffer pool, and some won’t be needed.

And that’s where the Debian startup script breaks down entirely, because it doesn’t follow this pattern. It’s going to open every table, regardless of whether user queries require it or not. On big servers I’ve seen it literally run for days (or longer). In the meanwhile, it’ll interfere with everything else going on. Look what happens:

Notice all those processes in ‘statistics’ status. Why is that happening? Look at SHOW INNODB STATUS:

Everyone is waiting for mutexes, and they are all waiting for thread 1158064464 which has reserved it. If you hunt through the TRANSACTIONS section, you can see the OS thread IDs, and that one is the debian-sys-maint thread. You also see the other threads:

And correlating the thread ID back to the semaphores, you see thread 1159956816 is waiting for the semaphore.

Notice that this is effectively a global lock. The debian-sys-maint thread is not touching the same tables as the other queries; it’s just touching the same internal structures. So a user working on table A can interfere with a user that wants access to table B.

The real solution is to disable this startup process. It’s not even needed for InnoDB. Sooner or later you’ll find yourself fighting with it. You can just put “exit 0;” at the top.

The solution I chose in this case?

Immediately afterward everything cleared up.

Share this post

Comments (13)

  • Erik Jacobson

    Very interesting. I’ve noticed how long this process takes, but usually just accepted it as a fact of life for data consistency, similar to fsck. I have killed it off in the past though when I really needed the server to start running immediately.

    It may be worth forwarding this along to their MySQL bugs page, as I’m sure they’d take action with the documentation provided here, and this is certainly something squarely in their hands as opposed to upstream:;dist=unstable

    Nice find though!

    January 28, 2009 at 11:08 am
  • ch

    Note that this shouldn’t be a problem with MySQL from Debian lenny, as it ships with init-scripts which will not run CHECK TABLE on non-MYISAM tables.

    January 28, 2009 at 11:45 am
  • Olivier B.

    Actually we only comment the call of “check_for_crashed_tables;” in the Debian script.

    January 28, 2009 at 12:37 pm

    I have also used the “KILL 7” approach in the past and found that another thread is often opened up immediately with a “CHECK TABLE” on the next table in the database. I needed to keep killing threads until it gets to the end. [Ubuntu 8.04 Hardy]

    January 28, 2009 at 2:03 pm
  • Brice Figureau

    My first action after installing mysql on Debian is to comment the check_for_crashed call (actually not really me, but Puppet is doing it for me).

    January 28, 2009 at 11:57 pm
  • Vide

    Yep, the stock Mysql Debian init script sucks so badly that it’s almost mandatory for every sysadmin out there with a real Mysql installation to fine tune them. Moreover it sucks almost as well that scripts in the .deb packages stop/start Mysql without asking. There are situations in which you want to update the binary quickly but you want a controlled restart.

    January 29, 2009 at 2:24 am
  • Norbert Tretkowski

    Vide, just drop a mail to the Debian BTS with your suggestions and patches. It’s too late to change things for lenny, but we can talk about your suggestions and patches for squeeze.

    Btw, I’m using the stock init scripts in “real mysql installations” (50+ servers), and they are working just fine.

    January 29, 2009 at 4:29 am
  • Baron Schwartz

    Changing the script isn’t enough to avoid the problems with the data dictionary, BTW. Just touching the table causes InnoDB to allocate space for it, which it will never release again until it’s restarted. And you have to touch the table to find out its engine, so you can’t know a priori which tables not to touch. Any scripts that query the INFORMATION_SCHEMA upon startup are also a very bad idea on installations with lots of tables.

    I still advise to disable the script, period, unless you know you want it enabled.

    January 29, 2009 at 7:02 am
  • Baron Schwartz

    Norbert, I don’t think it’s the init script Vide meant; it’s the install/deinstall. I agree — it shouldn’t try to start/stop automatically. This is not a mistake unique to Debian đŸ™‚

    January 29, 2009 at 7:05 am
  • peter


    In reality it is not clear to me why do it this way all together.
    If you want tables to be checked and repaired on startup myisam_recover is the decent option. If this causes problems because MySQL starts to check and repair a lot of tables at the same time blocking all connections may be MyISAM is simply not the right choice for you.

    Running check in the background is the broken middle ground – you still have some queries ran against corrupted MyISAM tables which can cause wrong query results or further corruption and you can still get MySQL stalled/running out of connections when a lot of connections block waiting for some large commonly accessed table which is being checked.

    January 29, 2009 at 7:45 pm
  • Baron Schwartz

    I agree 100%. One thing I didn’t say — there might be a reason for a custom startup script — but it’s not this. Just don’t put mysql_check_upgrade (that only needs to be run *one time*!) and don’t put mysqlcheck in it. But you might put a script to warm up your indexes or something like that. Something that’s too complex to put in the –init-file option.

    January 29, 2009 at 7:48 pm
  • g

    Yet another brain damaged Debian “improvement”.

    Memo to debian package maintainers: You are *package maintainers*. If you want to change the way MySQL *behaves*, SUBMIT A PATCH LIKE EVERYONE ELSE, IF FOR NO OTHER REASON THAN TO HAVE IT REFLECTED IN THE OFFICIAL DOCUMENTATION EVERYONE (except a few of us crusty old farts who don’t trust anyone or anything we don’t build ourselves) RELIES UPON.


    January 31, 2009 at 8:26 pm
  • Markus

    g, you don’t need to cry, as ch wrote above the behaviour was already changed about a year ago.

    February 12, 2009 at 1:14 am

Comments are closed.

Use Percona's Technical Forum to ask any follow-up questions on this blog topic.