innotop - A MySQL and InnoDB monitor program.
innotop connects to a MySQL database server and retrieves information from it, then displays it in a manner similar to the UNIX top program. innotop uses the data from SHOW VARIABLES, SHOW GLOBAL STATUS, SHOW FULL PROCESSLIST, and SHOW ENGINE INNODB STATUS, among other things.
innotop operates in one of several modes, and you control it by key presses. You can find a complete list of all available keys at any time by pressing '?' for help. See below for a list of modes.
Note: if there's been a huge deadlock, the InnoDB monitor text may be truncated, and the transaction and other information may not be available. In this case, you should enter Deadlock mode, make a note of anything you care about, and use the 'w' command to deliberately create a very small deadlock, so the monitor text won't be truncated anymore.
This documentation is text that can get out of date. The help text displayed when you press '?' is generated by innotop looking at itself, and will never be out of date or incomplete.
Fortunately or unfortunately, depending on your point of view, innotop is highly configurable. You can choose what to display, what order to sort it in, and so on. Every tabular display allows you to choose the columns and their order. You can remove a tabular display section entirely by removing all its columns.
There are no required command-line arguments. Just start the program. It will create a default configuration file for you, asking you to fill in a couple variables it needs. After that, the configuration file gets saved every time you exit innotop. You can hand-edit it when innotop isn't running.
You can specify certain options on the command-line. Run `innotop -help' for details.
You can also configure everything that matters while it's running. Just press the '$' key, and everything relevant to the current mode will be displayed. Type the name of the variable you want to configure, and a dialog will show you all sorts of info about the variable, its current value, and possible values. This is probably more convenient than editing the file by hand, since you won't get all that helpful information when editing by hand.
innotop has a bunch of different modes. The following is a brief, incomplete description of each. Remember, you can always get the authoritative help by pressing '?'.
This mode shows every transaction in the InnoDB monitor's output, in query-list format. This mode is the reason I wrote innotop. It is the most important for my daily monitoring activities.
It has tons of options, including the ability to choose a sort column and sort order, hide inactive transactions, hide innotop's own transaction, and choose columns for the display.
You can also add filters to each column (including ones not displayed), much like a SQL WHERE clause. Filters are Perl regular expressions.
From this mode you can also enter the Query Analysis mode, to EXPLAIN a query.
This mode shows you information about any current InnoDB lock waits. This information comes from the TRANSACTIONS section of the InnoDB status text. If you have a very busy server, you may have frequent lock waits; it helps to be able to see which table and index is the ``hot spot'' for locks. If your server is running pretty well, this mode will usually have nothing to display.
A second section of the display shows any waits in the OS wait array. This comes from a separate section of the status text. If you see frequent waits, your server is running in high concurrency. This section deals with thread semaphores, not transactional lock waits.
This section comes from MySQL's SHOW OPEN TABLES command. By default it is filtered to show tables which are in use by one or more queries, so you can get a quick look at which tables are 'hot'. You can use this to guess which tables might be locked implicitly.
You enter this mode with the 'O' key.
This mode is very much like mytop's query list mode. It shows a list of all processes, garnered from SHOW FULL PROCESSLIST. This mode does not show InnoDB-related information. This is probably one of the most useful modes for general usage.
It has a bunch of options, including an informative header. You can also show or hide many things, such as the header, innotop's own process, and sleeping processes. You can choose a sort column and reverse the sort.
You can also add filters to each column (including ones not displayed), much like a SQL WHERE clause. Filters are Perl regular expressions.
From this mode you can also enter the Query Analysis mode, to EXPLAIN a query.
This mode shows the last detected InnoDB deadlock. It displays the transactions involved, the locks that were held and waited for, and the query each was running. It also allows you to deliberately create a small deadlock, to obliterate the (potentially very large) deadlock information.
This mode shows the last InnoDB foreign key error information, such as the table where it happened, when and who and what query caused it, and so on.
InnoDB has a huge variety of foreign key error messages, and many of them are just hard to parse. innotop doesn't always do the best job here, but there's so much code devoted to parsing this messy, unparseable output that innotop is likely never to be perfect in this regard. If innotop doesn't show you what you need to see, just look at the status text directly.
This mode shows the InnoDB row operations and semaphore information. It shows a synopsis of per-second average information, and what the status of various things is. It also shows when there's information in the wait array.
This mode shows the InnoDB buffer pool, buffer memory usage, insert buffer, and adaptive hash index.
This mode shows InnoDB's I/O statistics, including the I/O threads, pending I/O, file I/O miscellaneous, and log statistics.
This mode calculates several types of per-second statistics, such as queries per second, scales them against a maximum, and prints them out as a ``graph'' in the style of <tload>. It's similar to the Load Statistics mode, except it's a graph instead of numbers.
This mode calculates several types of per-second statistics, such as queries per second, and prints them out in the style of <vmstat>. It's similar to the Load Graph mode, except it's a numbers instead of a graph.
You can choose whether to show the statistics over all time or the interval at which innotop refreshes. You can choose whether to show absolute values or per-second averages. You can also increase and decrease the digits of precision, and toggle between short and long numbers modes (e.g. 1k vs. 1,024).
This mode displays any variables you please from SHOW GLOBAL STATUS and SHOW VARIABLES. It displays not only the current values, but previous values too; you choose how many (two through nine). You have the same options as in Load Statistics mode.
You can save 10 presets and toggle between them with the keys 0 through 9. I've included some samples with innotop already. They show you things about the query cache, how many index and table scans are happening, and so forth. You can make your own too, of course.
This mode is useful in Query List and Transaction modes. You enter it from those modes with the 'e' or 'f' keys, to 'explain' or 'show full text' of a query. Use 'q' to exit this mode and return to the previous mode.
In this mode, you can 'explain' a query, which executes EXPLAIN EXTENDED whatever query you selected in Query List or Transaction mode. You can flip back and forth between explaining the query, looking at its full text, and viewing the MySQL optimization of the query (only available in newer versions of MySQL, where SHOW WARNINGS after EXPLAIN EXTENDED shows the optimization). You will also see partition information, which will be blank unless your version of MySQL supports partitions.
You must connect to the DB server as a user who has the SUPER privilege for many of the functions. If you don't have the SUPER privilege, you may still be able to run some functions that don't require InnoDB information.
I think everything you need to run innotop is distributed either with Perl, or with innotop itself. You need DBI, obviously. You also need the InnoDBParser module, and Term::ReadKey. If you have Time::HiRes, innotop will use it. If you have Term::ANSIColor, innotop will use it to format headers more readably and compactly. (Under Microsoft Windows, you also need Win32::Console::ANSI for terminal formatting codes to be honored).
I run innotop on Gentoo GNU/Linux, and I've had feedback from people successfully running it on Red Hat, CentOS, Solaris, and Mac OSX. I don't see any reason why it won't work on other UNIX-ish operating systems, but I don't know for sure. As of version 0.1.155, it also runs on Windows under ActivePerl without problem.
I have perl v5.8.8 installed, and I've had reports of it working on 5.8.5 but I don't know about other versions. I use innotop on MySQL version 4.1 and 5.0 and have heard of others using it on these same versions. I don't know of any reasons it shouldn't work with other versions of perl and MySQL, but I don't know for sure. Please test and help me fix any problems you find.
$homepath/.innotop is used to store configuration information.
You may also choose to have innotop do ``core dumps'' if there are errors. In that case you can choose a file in which to put the dump. See the configuration file.
THIS PROGRAM IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
This program is copyright (c) 2006 Baron Schwartz, baron at xaprb dot com. All rights reserved. Feedback and improvements are gratefully received.
Execute innotop and press '!' to see this information at any time.
Baron Schwartz, baron at xaprb dot com.
If you find any problems with innotop, please contact me. Specifically, if you find any problems with parsing the InnoDB monitor output, I would greatly appreciate you sending me the full text of the monitor output that caused the problem.
It does way too much, and tries to be all things to all people.
Not really a bug, but asking InnoDB for its monitor output has a side effect. Certain InnoDB statistics are calculated from the last time the request was issued, so multiple users may have an effect on the data each other sees.