|
NAMEinnotop - MySQL and InnoDB transaction/status monitor.SYNOPSISTo monitor servers normally:innotop To monitor InnoDB status information from a file: innotop /var/log/mysql/mysqld.err To run innotop non-interactively in a pipe-and-filter configuration: innotop --count 5 -d 1 -n To monitor a database on another system using a particular username and password: innotop -u <username> -p <password> -h <hostname> DESCRIPTIONinnotop monitors MySQL servers. Each of its modes shows you a different aspect of what's happening in the server. For example, there's a mode for monitoring replication, one for queries, and one for transactions. innotop refreshes its data periodically, so you see an updating view.innotop has lots of features for power users, but you can start and run it with virtually no configuration. If you're just getting started, see "QUICK-START". Press '?' at any time while running innotop for context-sensitive help. QUICK-STARTTo start innotop, open a terminal or command prompt. If you have installed innotop on your system, you should be able to just type "innotop" and press Enter; otherwise, you will need to change to innotop's directory and type "perl innotop".With no options specified, innotop will attempt to connect to a MySQL server on localhost using mysql_read_default_group=client for other connection parameters. If you need to specify a different username and password, use the -u and -p options, respectively. To monitor a MySQL database on another host, use the -h option. After you've connected, innotop should show you something like the following: [RO] Query List (? for help) localhost, 01:11:19, 449.44 QPS, 14/7/163 con/run CXN When Load QPS Slow QCacheHit KCacheHit BpsIn BpsOut localhost Total 0.00 1.07k 697 0.00% 98.17% 476.83k 242.83k CXN Cmd ID User Host DB Time Query localhost Query 766446598 test 10.0.0.1 foo 00:02 INSERT INTO table ( (This sample is truncated at the right so it will fit on a terminal when running 'man innotop') If your server is busy, you'll see more output. Notice the first line on the screen, which tells you that readonly is set to true ([RO]), what mode you're in and what server you're connected to. You can change to other modes with keystrokes; press 'T' to switch to a list of InnoDB transactions, for example. Press the '?' key to see what keys are active in the current mode. You can press any of these keys and innotop will either take the requested action or prompt you for more input. If your system has Term::ReadLine support, you can use TAB and other keys to auto-complete and edit input. To quit innotop, press the 'q' key. OPTIONSinnotop is mostly configured via its configuration file, but some of the configuration options can come from the command line. You can also specify a file to monitor for InnoDB status output; see "MONITORING A FILE" for more details.You can negate some options by prefixing the option name with --no. For example, --noinc (or --no-inc) negates "--inc".
HOTKEYSinnotop is interactive, and you control it with key-presses.
Press '?' at any time to see the currently active keys and what they do. MODESEach of innotop's modes retrieves and displays a particular type of data from the servers you're monitoring. You switch between modes with uppercase keys. The following is a brief description of each mode, in alphabetical order. To switch to the mode, press the key listed in front of its heading in the following list:
INNOTOP STATUSThe first line innotop displays is a "status bar" of sorts. What it contains depends on the mode you're in, and what servers you're monitoring. The first few words are always [RO] (if readonly is set to 1), the innotop mode, such as "InnoDB Txns" for T mode, followed by a reminder to press '?' for help at any time.ONE SERVERThe simplest case is when you're monitoring a single server. In this case, the name of the connection is next on the status line. This is the name you gave when you created the connection -- most likely the MySQL server's hostname. This is followed by the server's uptime.If you're in an InnoDB mode, such as T or B, the next word is "InnoDB" followed by some information about the SHOW INNODB STATUS output used to render the screen. The first word is the number of seconds since the last SHOW INNODB STATUS, which InnoDB uses to calculate some per-second statistics. The next is a smiley face indicating whether the InnoDB output is truncated. If the smiley face is a :-), all is well; there is no truncation. A :^| means the transaction list is so long, InnoDB has only printed out some of the transactions. Finally, a frown :-( means the output is incomplete, which is probably due to a deadlock printing too much lock information (see "D: InnoDB Deadlocks"). The next two words indicate the server's queries per second (QPS) and how many threads (connections) exist. Finally, the server's version number is the last thing on the line. MULTIPLE SERVERSIf you are monitoring multiple servers (see "SERVER CONNECTIONS"), the status line does not show any details about individual servers. Instead, it shows the names of the connections that are active. Again, these are connection names you specified, which are likely to be the server's hostname. A connection that has an error is prefixed with an exclamation point.If you are monitoring a group of servers (see "SERVER GROUPS"), the status line shows the name of the group. If any connection in the group has an error, the group's name is followed by the fraction of the connections that don't have errors. See "ERROR HANDLING" for more details about innotop's error handling. MONITORING A FILEIf you give a filename on the command line, innotop will not connect to ANY servers at all. It will watch the specified file for InnoDB status output and use that as its data source. It will always show a single connection called 'file'. And since it can't connect to a server, it can't determine how long the server it's monitoring has been up; so it calculates the server's uptime as time since innotop started running.SERVER ADMINISTRATIONWhile innotop is primarily a monitor that lets you watch and analyze your servers, it can also send commands to servers. The most frequently useful commands are killing queries and stopping or starting slaves.You can kill a connection, or in newer versions of MySQL kill a query but not a connection, from "Q: Query List" and "T: InnoDB Transactions" modes. Press 'k' to issue a KILL command, or 'x' to issue a KILL QUERY command. innotop will prompt you for the server and/or connection ID to kill (innotop does not prompt you if there is only one possible choice for any input). innotop pre-selects the longest-running query, or the oldest connection. Confirm the command with 'y'. In "Slave Replication Status"" in "M: Master mode, you can start and stop slaves with the 'a' and 'o' keys, respectively. You can send these commands to many slaves at once. innotop fills in a default command of START SLAVE or STOP SLAVE for you, but you can actually edit the command and send anything you wish, such as SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1 to make the slave skip one binlog event when it starts. You can also ask innotop to calculate the earliest binlog in use by any slave and issue a PURGE MASTER LOGS on the master. Use the 'b' key for this. innotop will prompt you for a master to run the command on, then prompt you for the connection names of that master's slaves (there is no way for innotop to determine this reliably itself). innotop will find the minimum binlog in use by these slave connections and suggest it as the argument to PURGE MASTER LOGS. in "U: User Statistics" mode, you can use the 's' key to start and stop the collection of the statistics data for TABLE_STATISTICS and similar. SERVER CONNECTIONSWhen you create a server connection using '@', innotop asks you for a series of inputs, as follows:
Once you finish answering these questions, you should be connected to a server. But innotop isn't limited to monitoring a single server; you can define many server connections and switch between them by pressing the '@' key. See "SWITCHING BETWEEN CONNECTIONS". SERVER GROUPSIf you have multiple MySQL instances, you can put them into named groups, such as 'all', 'masters', and 'slaves', which innotop can monitor all together.You can choose which group to monitor with the '#' key, and you can press the TAB key to switch to the next group. If you're not currently monitoring a group, pressing TAB selects the first group. To create a group, press the '#' key and type the name of your new group, then type the names of the connections you want the group to contain. SWITCHING BETWEEN CONNECTIONSinnotop lets you quickly switch which servers you're monitoring. The most basic way is by pressing the '@' key and typing the name(s) of the connection(s) you want to use. This setting is per-mode, so you can monitor different connections in each mode, and innotop remembers which connections you choose.You can quickly switch to the 'next' connection in alphabetical order with the 'n' key. If you're monitoring a server group (see "SERVER GROUPS") this will switch to the first connection. You can also type many connection names, and innotop will fetch and display data from them all. Just separate the connection names with spaces, for example "server1 server2." Again, if you type the name of a connection that doesn't exist, innotop will prompt you for connection information and create the connection. Another way to monitor multiple connections at once is with server groups. You can use the TAB key to switch to the 'next' group in alphabetical order, or if you're not monitoring any groups, TAB will switch to the first group. innotop does not fetch data in parallel from connections, so if you are monitoring a large group or many connections, you may notice increased delay between ticks. When you monitor more than one connection, innotop's status bar changes. See "INNOTOP STATUS". ERROR HANDLINGError handling is not that important when monitoring a single connection, but is crucial when you have many active connections. A crashed server or lost connection should not crash innotop. As a result, innotop will continue to run even when there is an error; it just won't display any information from the connection that had an error. Because of this, innotop's behavior might confuse you. It's a feature, not a bug!innotop does not continue to query connections that have errors, because they may slow innotop and make it hard to use, especially if the error is a problem connecting and causes a long time-out. Instead, innotop retries the connection occasionally to see if the error still exists. If so, it will wait until some point in the future. The wait time increases in ticks as the Fibonacci series, so it tries less frequently as time passes. Since errors might only happen in certain modes because of the SQL commands issued in those modes, innotop keeps track of which mode caused the error. If you switch to a different mode, innotop will retry the connection instead of waiting. By default innotop will display the problem in red text at the bottom of the first table on the screen. You can disable this behavior with the "show_cxn_errors_in_tbl" configuration option, which is enabled by default. If the "debug" option is enabled, innotop will display the error at the bottom of every table, not just the first. And if "show_cxn_errors" is enabled, innotop will print the error text to STDOUT as well. Error messages might only display in the mode that caused the error, depending on the mode and whether innotop is avoiding querying that connection. NON-INTERACTIVE OPERATIONYou can run innotop in non-interactive mode, in which case it is entirely controlled from the configuration file and command-line options. To start innotop in non-interactive mode, give the L"<--nonint"> command-line option. This changes innotop's behavior in the following ways:
CONFIGURINGNearly everything about innotop is configurable. Most things are possible to change with built-in commands, but you can also edit the configuration file.While running innotop, press the '$' key to bring up the configuration editing dialog. Press another key to select the type of data you want to edit:
CONFIGURATION FILEinnotop's default configuration file locations are $HOME/.innotop and /usr/local/etc/innotop.conf, and they are looked for in that order. If the first configuration file exists, the second will not be processed. Those can be overridden with the "--config" command-line option. You can edit it by hand safely, however innotop reads the configuration file when it starts, and, if readonly is set to 0, writes it out again when it exits. Thus, if readonly is set to 0, any changes you make by hand while innotop is running will be lost.innotop doesn't store its entire configuration in the configuration file. It has a huge set of default configuration values that it holds only in memory, and the configuration file only overrides these defaults. When you customize a default setting, innotop notices, and then stores the customizations into the file. This keeps the file size down, makes it easier to edit, and makes upgrades easier. A configuration file is read-only be default. You can override that with "--write". See "readonly". The configuration file is arranged into sections like an INI file. Each section begins with [section-name] and ends with [/section-name]. Each section's entries have a different syntax depending on the data they need to store. You can put comments in the file; any line that begins with a # character is a comment. innotop will not read the comments, so it won't write them back out to the file when it exits. Comments in read-only configuration files are still useful, though. The first line in the file is innotop's version number. This lets innotop notice when the file format is not backwards-compatible, and upgrade smoothly without destroying your customized configuration. The following list describes each section of the configuration file and the data it contains:
CUSTOMIZINGYou can customize innotop a great deal. For example, you can:
All these and more are explained in the following sections. TABLESA table is what you'd expect: a collection of columns. It also has some other properties, such as a caption. Filters, sorting rules, and colorization rules belong to tables and are covered in later sections.Internally, table meta-data is defined in a data structure called %tbl_meta. This hash holds all built-in table definitions, which contain a lot of default instructions to innotop. The meta-data includes the caption, a list of columns the user has customized, a list of columns, a list of visible columns, a list of filters, color rules, a sort-column list, sort direction, and some information about the table's data sources. Most of this is customizable via the table editor (see "TABLE EDITOR"). You can choose which tables to show by pressing the '$' key. See "MODES" and "TABLES". The table life-cycle is as follows:
The lifecycle is slightly different if the table is pivoted, as noted above. To clarify, if the table is pivoted, the process is extract, group, transform, pivot, filter, sort, create. If it's not pivoted, the process is extract, filter, sort, group, color, transform, create. This slightly convoluted process doesn't map all that well to SQL, but pivoting complicates things pretty thoroughly. Roughly speaking, filtering and sorting happen as late as needed to effect the final result as you might expect, but as early as possible for efficiency. Each built-in table is described below:
COLUMNSColumns belong to tables. You can choose a table's columns by pressing the '^' key, which starts the "TABLE EDITOR" and lets you choose and edit columns. Pressing 'e' from within the table editor lets you edit the column's properties:
FILTERSFilters remove rows from the display. They behave much like a WHERE clause in SQL. innotop has several built-in filters, which remove irrelevant information like inactive queries, but you can define your own as well. innotop also lets you create quick-filters, which do not get saved to the configuration file, and are just an easy way to quickly view only some rows.You can enable or disable a filter on any table. Press the '%' key (mnemonic: % looks kind of like a line being filtered between two circles) and choose which table you want to filter, if asked. You'll then see a list of possible filters and a list of filters currently enabled for that table. Type the names of filters you want to apply and press Enter. USER-DEFINED FILTERS If you type a name that doesn't exist, innotop will prompt you to create the filter. Filters are easy to create if you know Perl, and not hard if you don't. What you're doing is creating a subroutine that returns true if the row should be displayed. The row is a hash reference passed to your subroutine as $set. For example, imagine you want to filter the processlist table so you only see queries that have been running more than five minutes. Type a new name for your filter, and when prompted for the subroutine body, press TAB to initiate your terminal's auto-completion. You'll see the names of the columns in the "processlist" table (innotop generally tries to help you with auto-completion lists). You want to filter on the 'time' column. Type the text "$set->{time} > 300" to return true when the query is more than five minutes old. That's all you need to do. In other words, the code you're typing is surrounded by an implicit context, which looks like this: sub filter { my ( $set ) = @_; # YOUR CODE HERE } If your filter doesn't work, or if something else suddenly behaves differently, you might have made an error in your filter, and innotop is silently catching the error. Try enabling "debug" to make innotop throw an error instead. QUICK-FILTERS innotop's quick-filters are a shortcut to create a temporary filter that doesn't persist when you restart innotop. To create a quick-filter, press the '/' key. innotop will prompt you for the column name and filter text. Again, you can use auto-completion on column names. The filter text can be just the text you want to "search for." For example, to filter the "processlist" table on queries that refer to the products table, type '/' and then 'info product'. Internally, the filter is compiled into a subroutine like this: sub filter { my ( $set ) = @_; $set->{info} =~ m/product/; } The filter text can actually be any Perl regular expression, but of course a literal string like 'product' works fine as a regular expression. What if you want the filter to discard matching rows, rather than showing matching rows? If you're familiar with Perl regular expressions, you might guess how to do this. You have to use a zero-width negative lookahead assertion. If you don't know what that means, don't worry. Let's filter out all rows where the command is Gandalf. Type the following: 1. / 2. cmd ^(?!Gandalf) Behind the scenes innotop compiles the quick-filter into a specially tagged filter that is otherwise like any other filter. It just isn't saved to the configuration file. To clear quick-filters, press the '\' key and innotop will clear them all at once. SORTINGinnotop has sensible built-in defaults to sort the most important rows to the top of the table. Like anything else in innotop, you can customize how any table is sorted.To start the sort dialog, start the "TABLE EDITOR" with the '^' key, choose a table if necessary, and press the 's' key. You'll see a list of columns you can use in the sort expression and the current sort expression, if any. Enter a list of columns by which you want to sort and press Enter. If you want to reverse sort, prefix the column name with a minus sign. For example, if you want to sort by column a ascending, then column b descending, type 'a -b'. You can also explicitly add a + in front of columns you want to sort ascending, but it's not required. Some modes have keys mapped to open this dialog directly, and to quickly reverse sort direction. Press '?' as usual to see which keys are mapped in any mode. GROUPINGinnotop can group, or aggregate, rows together (the terms are used interchangeably). This is quite similar to an SQL GROUP BY clause. You can specify to group on certain columns, or if you don't specify any, the entire set of rows is treated as one group. This is quite like SQL so far, but unlike SQL, you can also select un-grouped columns. innotop actually aggregates every column. If you don't explicitly specify a grouping function, the default is 'first'. This is basically a convenience so you don't have to specify an aggregate function for every column you want in the result.You can quickly toggle grouping on a table with the '=' key, which toggles its aggregate property. This property doesn't persist to the config file. The columns by which the table is grouped are specified in its group_by property. When you turn grouping on, innotop places the group_by columns at the far left of the table, even if they're not supposed to be visible. The rest of the visible columns appear in order after them. Two tables have default group_by lists and a count column built in: "processlist" and "innodb_transactions". The grouping is by connection and status, so you can quickly see how many queries or transactions are in a given status on each server you're monitoring. The time columns are aggregated as a sum; other columns are left at the default 'first' aggregation. By default, the table shown in "S: Variables & Status" mode also uses grouping so you can monitor variables and status across many servers. The default aggregation function in this mode is 'avg'. Valid grouping functions are defined in the %agg_funcs hash. They include
Here's an example of grouping at work. Suppose you have a very busy server with hundreds of open connections, and you want to see how many connections are in what status. Using the built-in grouping rules, you can press 'Q' to enter "Q: Query List" mode. Press '=' to toggle grouping (if necessary, select the "processlist" table when prompted). Your display might now look like the following: Query List (? for help) localhost, 32:33, 0.11 QPS, 1 thd, 5.0.38-log CXN Cmd Cnt ID User Host Time Query localhost Query 49 12933 webusr localhost 19:38 SELECT * FROM localhost Sending Da 23 2383 webusr localhost 12:43 SELECT col1, localhost Sleep 120 140 webusr localhost 5:18:12 localhost Statistics 12 19213 webusr localhost 01:19 SELECT * FROM That's actually quite a worrisome picture. You've got a lot of idle connections (Sleep), and some connections executing queries (Query and Sending Data). That's okay, but you also have a lot in Statistics status, collectively spending over a minute. That means the query optimizer is having a really hard time generating execution plans for your statements. Something is wrong; it should normally take milliseconds to plan queries. You might not have seen this pattern if you didn't look at your connections in aggregate. (This is a made-up example, but it can happen in real life). PIVOTINGinnotop can pivot a table for more compact display, similar to a Pivot Table in a spreadsheet (also known as a crosstab). Pivoting a table makes columns into rows. Assume you start with this table:foo bar === === 1 3 2 4 After pivoting, the table will look like this: name set0 set1 ==== ==== ==== foo 1 2 bar 3 4 To get reasonable results, you might need to group as well as pivoting. innotop currently does this for "S: Variables & Status" mode. COLORSBy default, innotop highlights rows with color so you can see at a glance which rows are more important. You can customize the colorization rules and add your own to any table. Open the table editor with the '^' key, choose a table if needed, and press 'o' to open the color editor dialog.The color editor dialog displays the rules applied to the table, in the order they are evaluated. Each row is evaluated against each rule to see if the rule matches the row; if it does, the row gets the specified color, and no further rules are evaluated. The rules look like the following: state eq Locked black on_red cmd eq Sleep white user eq system user white cmd eq Connect white cmd eq Binlog Dump white time > 600 red time > 120 yellow time > 60 green time > 30 cyan This is the default rule set for the "processlist" table. In order of priority, these rules make locked queries black on a red background, "gray out" connections from replication and sleeping queries, and make queries turn from cyan to red as they run longer. (For some reason, the ANSI color code "white" is actually a light gray. Your terminal's display may vary; experiment to find colors you like). You can use keystrokes to move the rules up and down, which re-orders their priority. You can also delete rules and add new ones. If you add a new rule, innotop prompts you for the column, an operator for the comparison, a value against which to compare the column, and a color to assign if the rule matches. There is auto-completion and prompting at each step. The value in the third step needs to be correctly quoted. innotop does not try to quote the value because it doesn't know whether it should treat the value as a string or a number. If you want to compare the column against a string, as for example in the first rule above, you should enter 'Locked' surrounded by quotes. If you get an error message about a bareword, you probably should have quoted something. EXPRESSIONSExpressions are at the core of how innotop works, and are what enables you to extend innotop as you wish. Recall the table lifecycle explained in "TABLES". Expressions are used in the earliest step, where it extracts values from a data source to form rows.It does this by calling a subroutine for each column, passing it the source data set, a set of current values, and a set of previous values. These are all needed so the subroutine can calculate things like the difference between this tick and the previous tick. The subroutines that extract the data from the set are compiled from expressions. This gives significantly more power than just naming the values to fill the columns, because it allows the column's value to be calculated from whatever data is necessary, but avoids the need to write complicated and lengthy Perl code. innotop begins with a string of text that can look as simple as a value's name or as complicated as a full-fledged Perl expression. It looks at each 'bareword' token in the string and decides whether it's supposed to be a key into the $set hash. A bareword is an unquoted value that isn't already surrounded by code-ish things like dollar signs or curly brackets. If innotop decides that the bareword isn't a function or other valid Perl code, it converts it into a hash access. After the whole string is processed, innotop compiles a subroutine, like this: sub compute_column_value { my ( $set, $cur, $pre ) = @_; my $val = # EXPANDED STRING GOES HERE return $val; } Here's a concrete example, taken from the header table "q_header" in "Q: Query List" mode. This expression calculates the qps, or Queries Per Second, column's values, from the values returned by SHOW STATUS: Queries/Uptime_hires innotop decides both words are barewords, and transforms this expression into the following Perl code: $set->{Queries}/$set->{Uptime_hires} When surrounded by the rest of the subroutine's code, this is executable Perl that calculates a high-resolution queries-per-second value. The arguments to the subroutine are named $set, $cur, and $pre. In most cases, $set and $cur will be the same values. However, if "status_inc" is set, $cur will not be the same as $set, because $set will already contain values that are the incremental difference between $cur and $pre. Every column in innotop is computed by subroutines compiled in the same fashion. There is no difference between innotop's built-in columns and user-defined columns. This keeps things consistent and predictable. TRANSFORMATIONSTransformations change how a value is rendered. For example, they can take a number of seconds and display it in H:M:S format. The following transformations are defined:
TABLE EDITORThe innotop table editor lets you customize tables with keystrokes. You start the table editor with the '^' key. If there's more than one table on the screen, it will prompt you to choose one of them. Once you do, innotop will show you something like this:Editing table definition for Buffer Pool. Press ? for help, q to quit. name hdr label src cxn CXN Connection from which cxn buf_pool_size Size Buffer pool size IB_bp_buf_poo buf_free Free Bufs Buffers free in the b IB_bp_buf_fre pages_total Pages Pages total IB_bp_pages_t pages_modified Dirty Pages Pages modified (dirty IB_bp_pages_m buf_pool_hit_rate Hit Rate Buffer pool hit rate IB_bp_buf_poo total_mem_alloc Memory Total memory allocate IB_bp_total_m add_pool_alloc Add'l Pool Additional pool alloc IB_bp_add_poo The first line shows which table you're editing, and reminds you again to press '?' for a list of key mappings. The rest is a tabular representation of the table's columns, because that's likely what you're trying to edit. However, you can edit more than just the table's columns; this screen can start the filter editor, color rule editor, and more. Each row in the display shows a single column in the table you're editing, along with a couple of its properties such as its header and source expression (see "EXPRESSIONS"). The key mappings are Vim-style, as in many other places. Pressing 'j' and 'k' moves the highlight up or down. You can then (d)elete or (e)dit the highlighted column. You can also (a)dd a column to the table. This actually just activates one of the columns already defined for the table; it prompts you to choose from among the columns available but not currently displayed. Finally, you can re-order the columns with the '+' and '-' keys. You can do more than just edit the columns with the table editor, you can also edit other properties, such as the table's sort expression and group-by expression. Press '?' to see the full list, of course. If you want to really customize and create your own column, as opposed to just activating a built-in one that's not currently displayed, press the (n)ew key, and innotop will prompt you for the information it needs:
Once you've entered the required data, your table has a new column. There is no difference between this column and the built-in ones; it can have all the same properties and behaviors. innotop will write the column's definition to the configuration file, so it will persist across sessions. Here's an example: suppose you want to track how many times your slaves have retried transactions. According to the MySQL manual, the Slave_retried_transactions status variable gives you that data: "The total number of times since startup that the replication slave SQL thread has retried transactions. This variable was added in version 5.0.4." This is appropriate to add to the "slave_sql_status" table. To add the column, switch to the replication-monitoring mode with the 'M' key, and press the '^' key to start the table editor. When prompted, choose slave_sql_status as the table, then press 'n' to create the column. Type 'retries' as the column name, 'Retries' as the column header, and 'Slave_retried_transactions' as the source. Now the column is created, and you see the table editor screen again. Press 'q' to exit the table editor, and you'll see your column at the end of the table. VARIABLE SETSVariable sets are used in "S: Variables & Status" mode to define more easily what variables you want to monitor. Behind the scenes they are compiled to a list of expressions, and then into a column list so they can be treated just like columns in any other table, in terms of data extraction and transformations. However, you're protected from the tedious details by a syntax that ought to feel very natural to you: a SQL SELECT list.The data source for variable sets, and indeed the entire S mode, is the combination of SHOW STATUS, SHOW VARIABLES, and SHOW INNODB STATUS. Imagine that you had a huge table with one column per variable returned from those statements. That's the data source for variable sets. You can now query this data source just like you'd expect. For example: Queries, Uptime, Queries/Uptime as QPS Behind the scenes innotop will split that variable set into three expressions, compile them and turn them into a table definition, then extract as usual. This becomes a "variable set," or a "list of variables you want to monitor." innotop lets you name and save your variable sets, and writes them to the configuration file. You can choose which variable set you want to see with the 'c' key, or activate the next and previous sets with the '>' and '<' keys. There are many built-in variable sets as well, which should give you a good start for creating your own. Press 'e' to edit the current variable set, or just to see how it's defined. To create a new one, just press 'c' and type its name. You may want to use some of the functions listed in "TRANSFORMATIONS" to help format the results. In particular, "set_precision" is often useful to limit the number of digits you see. Extending the above example, here's how: Queries, Uptime, set_precision(Queries/Uptime) as QPS Actually, this still needs a little more work. If your "interval" is less than one second, you might be dividing by zero because Uptime is incremental in this mode by default. Instead, use Uptime_hires: Queries, Uptime, set_precision(Queries/Uptime_hires) as QPS This example is simple, but it shows how easy it is to choose which variables you want to monitor. PLUGINSinnotop has a simple but powerful plugin mechanism by which you can extend or modify its existing functionality, and add new functionality. innotop's plugin functionality is event-based: plugins register themselves to be called when events happen. They then have a chance to influence the event.An innotop plugin is a Perl module (.pm) file placed in innotop's "plugin_dir" directory. On UNIX systems, you can place a symbolic link to the module instead of putting the actual file there. innotop automatically discovers files named "*.pm". If there is a corresponding entry in the "plugins" configuration file section, innotop loads and activates the plugin. The module must conform to innotop's plugin interface. Additionally, the source code of the module must be written in such a way that innotop can inspect the file and determine the package name and description. Package Source Conventioninnotop inspects the plugin module's source to determine the Perl package name. It looks for a line of the form "package Foo;" and if found, considers the plugin's package name to be Foo. Of course the package name can be a valid Perl package name such as Foo::Bar, with double colons (::) and so on.It also looks for a description in the source code, to make the plugin editor more human-friendly. The description is a comment line of the form "# description: Foo", where "Foo" is the text innotop will consider to be the plugin's description. Plugin InterfaceThe innotop plugin interface is quite simple: innotop expects the plugin to be an object-oriented module it can call certain methods on. The methods are
Plugin VariablesThe plugin's constructor is passed a hash of innotop's variables, which it can manipulate. It is probably a good idea if the plugin object saves a copy of it for later use. The variables are defined in the innotop variable %pluggable_vars, and are as follows:
Plugin EventsEach event is defined somewhere in the innotop source code. When innotop runs that code, it executes the callback function for each plugin that expressed its interest in the event. innotop passes some data for each event. The events are defined in the %event_listener_for variable, and are as follows:
Simple Plugin ExampleThe easiest way to explain the plugin functionality is probably with a simple example. The following module adds a column to the beginning of every table and sets its value to 1. (If you copy and paste this example code, be sure to remove the first space from each line; lines such as '# description' must not start with whitespace).use strict; use warnings FATAL => 'all'; package Innotop::Plugin::Example; # description: Adds an 'example' column to every table sub new { my ( $class, %vars ) = @_; # Store reference to innotop's variables in $self my $self = bless { %vars }, $class; # Design the example column my $col = { hdr => 'Example', just => '', dec => 0, num => 1, label => 'Example', src => 'example', # Get data from this column in the data source tbl => '', trans => [], }; # Add the column to every table. my $tbl_meta = $vars{tbl_meta}; foreach my $tbl ( values %$tbl_meta ) { # Add the column to the list of defined columns $tbl->{cols}->{example} = $col; # Add the column to the list of visible columns unshift @{$tbl->{visible}}, 'example'; } # Be sure to return a reference to the object. return $self; } # I'd like to be called when a data set is being rendered into a table, please. sub register_for_events { my ( $self ) = @_; return qw(set_to_tbl_pre_filter); } # This method will be called when the event fires. sub set_to_tbl_pre_filter { my ( $self, $rows, $tbl ) = @_; # Set the example column's data source to the value 1. foreach my $row ( @$rows ) { $row->{example} = 1; } } 1; Plugin EditorThe plugin editor lets you view the plugins innotop discovered and activate or deactivate them. Start the editor by pressing $ to start the configuration editor from any mode. Press the 'p' key to start the plugin editor. You'll see a list of plugins innotop discovered. You can use the 'j' and 'k' keys to move the highlight to the desired one, then press the * key to toggle it active or inactive. Exit the editor and restart innotop for the changes to take effect.SQL STATEMENTSinnotop uses a limited set of SQL statements to retrieve data from MySQL for display. The statements are customized depending on the server version against which they are executed; for example, on MySQL 5 and newer, INNODB_STATUS executes "SHOW ENGINE INNODB STATUS", while on earlier versions it executes "SHOW INNODB STATUS". The statements are as follows:Statement SQL executed =================== =============================== INDEX_STATISTICS SELECT * FROM INFORMATION_SCHEMA.INDEX_STATISTICS INNODB_STATUS SHOW [ENGINE] INNODB STATUS KILL_CONNECTION KILL KILL_QUERY KILL QUERY OPEN_TABLES SHOW OPEN TABLES PROCESSLIST SHOW FULL PROCESSLIST SHOW_MASTER_LOGS SHOW MASTER LOGS SHOW_MASTER_STATUS SHOW MASTER STATUS SHOW_SLAVE_STATUS SHOW SLAVE STATUS SHOW_STATUS SHOW [GLOBAL] STATUS SHOW_VARIABLES SHOW [GLOBAL] VARIABLES TABLE_STATISTICS SELECT * FROM INFORMATION_SCHEMA.TABLE_STATISTICS DATA SOURCESEach time innotop extracts values to create a table (see "EXPRESSIONS" and "TABLES"), it does so from a particular data source. Largely because of the complex data extracted from SHOW INNODB STATUS, this is slightly messy. SHOW INNODB STATUS contains a mixture of single values and repeated values that form nested data sets.Whenever innotop fetches data from MySQL, it adds two extra bits to each set: cxn and Uptime_hires. cxn is the name of the connection from which the data came. Uptime_hires is a high-resolution version of the server's Uptime status variable, which is important if your "interval" setting is sub-second. Here are the kinds of data sources from which data is extracted:
MYSQL PRIVILEGES
SYSTEM REQUIREMENTSYou need Perl to run innotop, of course. You also need a few Perl modules: DBI, DBD::mysql, Term::ReadKey, and Time::HiRes. These should be included with most Perl distributions, but in case they are not, I recommend using versions distributed with your operating system or Perl distribution, not from CPAN. Term::ReadKey in particular has been known to cause problems if installed from CPAN.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). If you install Term::ReadLine, preferably Term::ReadLine::Gnu, you'll get nice auto-completion support. I run innotop on Gentoo GNU/Linux, Debian and Ubuntu, 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. It also runs on Windows under ActivePerl without problem. innotop has been used on MySQL versions 3.23.58, 4.0.27, 4.1.0, 4.1.22, 5.0.26, 5.1.15, and 5.2.3. If it doesn't run correctly for you, that is a bug that should be reported. FILES$HOMEDIR/.innotop and/or /usr/local/etc are used to store configuration information. Files include the configuration file innotop.conf, the core_dump file which contains verbose error messages if "debug" is enabled, and the plugins/ subdirectory.GLOSSARY OF TERMS
ACKNOWLEDGEMENTSThe following people and organizations are acknowledged for various reasons. Hopefully no one has been forgotten.Aaron Racine, Allen K. Smith, Aurimas Mikalauskas, Bartosz Fenski, Brian Miezejewski, Christian Hammers, Cyril Scetbon, Dane Miller, David Multer, Dr. Frank Ullrich, Giuseppe Maxia, Google.com Site Reliability Engineers, Google Code, Jan Pieter Kunst, Jari Aalto, Jay Pipes, Jeremy Zawodny, Johan Idren, Kristian Kohntopp, Lenz Grimmer, Maciej Dobrzanski, Michiel Betel, MySQL AB, Paul McCullagh, Sebastien Estienne, Sourceforge.net, Steven Kreuzer, The Gentoo MySQL Team, Trevor Price, Yaar Schnitman, and probably more people that have not been included. (If your name has been misspelled, it's probably out of fear of putting international characters into this documentation; earlier versions of Perl might not be able to compile it then). COPYRIGHT, LICENSE AND WARRANTYThis program is copyright (c) 2006 Baron Schwartz. Feedback and improvements are welcome.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 free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 2; OR the Perl Artistic License. On UNIX and similar systems, you can issue `man perlgpl' or `man perlartistic' to read these licenses. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. Execute innotop and press '!' to see this information at any time. AUTHOROriginally written by Baron Schwartz; currently maintained by Aaron Racine.BUGSYou can report bugs, ask for improvements, and get other help and support at <https://github.com/innotop/innotop>. There are mailing lists, a source code browser, a bug tracker, etc. Please use these instead of contacting the maintainer or author directly, as it makes our job easier and benefits others if the discussions are permanent and public. Of course, if you need to contact us in private, please do.
Visit the GSP FreeBSD Man Page Interface. |