1INNOTOP(1) User Contributed Perl Documentation INNOTOP(1)
2
6 innotop - MySQL and InnoDB transaction/status monitor.
7
9 To monitor servers normally:
10 innotop
12 To monitor InnoDB status information from a file:
14 innotop /var/log/mysql/mysqld.err
16 To run innotop non-interactively in a pipe-and-filter configuration:
18 innotop --count 5 -d 1 -n
20
22 innotop monitors MySQL servers. Each of its modes shows you a
23 different aspect of what's happening in the server. For example,
24 there's a mode for monitoring replication, one for queries, and one for
25 transactions. innotop refreshes its data periodically, so you see an
26 updating view.
27 innotop has lots of features for power users, but you can start and run
29 it with virtually no configuration. If you're just getting started,
30 see "QUICK-START". Press '?' at any time while running innotop for
31 context-sensitive help.
32
34 To start innotop, open a terminal or command prompt. If you have
35 installed innotop on your system, you should be able to just type
36 "innotop" and press Enter; otherwise, you will need to change to
37 innotop's directory and type "perl innotop".
38 The first thing innotop needs to know is how to connect to a MySQL
40 server. You can just enter the hostname of the server, for example
41 "localhost" or "127.0.0.1" if the server is on the same machine as
42 innotop. After this innotop will prompt you for a DSN (data source
43 name). You should be able to just accept the defaults by pressing
44 Enter.
45 When innotop asks you about a table to use when resetting InnoDB
47 deadlock information, just accept the default for now. This is an
48 advanced feature you can configure later (see "D: InnoDB Deadlocks" for
49 more).
50 If you have a .my.cnf file with your MySQL connection defaults, innotop
52 can read it, and you won't need to specify a username and password if
53 it's in that file. Otherwise, you should answer 'y' to the next couple
54 of prompts.
55 After this, you should be connected, and innotop should show you
57 something like the following:
58 InnoDB Txns (? for help) localhost, 01:11:19, InnoDB 10s :-), 50 QPS,
60 CXN History Versions Undo Dirty Buf Used Bufs Txns MaxTxn
62 localhost 7 2035 0 0 0.00% 92.19% 1 07:34
63 CXN ID User Host Txn Status Time Undo Query Tex
65 localhost 98379 user1 webserver ACTIVE 07:34 0 SELECT `c
66 localhost 98450 user1 webserver ACTIVE 01:06 0 INSERT IN
67 localhost 97750 user1 webserver not starte 00:00 0
68 localhost 98375 user1 appserver not starte 00:00 0
69 (This sample is truncated at the right so it will fit on a terminal
71 when running 'man innotop')
72 This sample comes from a quiet server with few transactions active. If
74 your server is busy, you'll see more output. Notice the first line on
75 the screen, which tells you what mode you're in and what server you're
76 connected to. You can change to other modes with keystrokes; press 'Q'
77 to switch to a list of currently running queries.
78 Press the '?' key to see what keys are active in the current mode. You
80 can press any of these keys and innotop will either take the requested
81 action or prompt you for more input. If your system has Term::ReadLine
82 support, you can use TAB and other keys to auto-complete and edit
83 input.
84 To quit innotop, press the 'q' key.
86
88 innotop is mostly configured via its configuration file, but some of
89 the configuration options can come from the command line. You can also
90 specify a file to monitor for InnoDB status output; see "MONITORING A
91 FILE" for more details.
92 You can negate some options by prefixing the option name with --no.
94 For example, --noinc (or --no-inc) negates "--inc".
95 --help
97 Print a summary of command-line usage and exit.
98 --color
100 Enable or disable terminal coloring. Corresponds to the "color"
101 config file setting.
102 --config
104 Specifies a configuration file to read. This option is non-sticky,
105 that is to say it does not persist to the configuration file
106 itself.
107 --nonint
109 Enable non-interactive operation. See "NON-INTERACTIVE OPERATION"
110 for more.
111 --count
113 Refresh only the specified number of times (ticks) before exiting.
114 Each refresh is a pause for "interval" seconds, followed by
115 requesting data from MySQL connections and printing it to the
116 terminal.
117 --delay
119 Specifies the amount of time to pause between ticks (refreshes).
120 Corresponds to the configuration option "interval".
121 --mode
123 Specifies the mode in which innotop should start. Corresponds to
124 the configuration option "mode".
125 --inc
127 Specifies whether innotop should display absolute numbers or
128 relative numbers (offsets from their previous values). Corresponds
129 to the configuration option "status_inc".
130 --version
132 Output version information and exit.
133
135 innotop is interactive, and you control it with key-presses.
136 · Uppercase keys switch between modes.
138 · Lowercase keys initiate some action within the current mode.
140 · Other keys do something special like change configuration or show
142 the innotop license.
143 Press '?' at any time to see the currently active keys and what they
145 do.
146
148 Each of innotop's modes retrieves and displays a particular type of
149 data from the servers you're monitoring. You switch between modes with
150 uppercase keys. The following is a brief description of each mode, in
151 alphabetical order. To switch to the mode, press the key listed in
152 front of its heading in the following list:
153 B: InnoDB Buffers
155 This mode displays information about the InnoDB buffer pool, page
156 statistics, insert buffer, and adaptive hash index. The data comes
157 from SHOW INNODB STATUS.
158 This mode contains the "buffer_pool", "page_statistics",
160 "insert_buffers", and "adaptive_hash_index" tables by default.
161 C: Command Summary
163 This mode is similar to mytop's Command Summary mode. It shows the
164 "cmd_summary" table, which looks something like the following:
165 Command Summary (? for help) localhost, 25+07:16:43, 2.45 QPS, 3 thd, 5.0.40
167 _____________________ Command Summary _____________________
168 Name Value Pct Last Incr Pct
169 Select_scan 3244858 69.89% 2 100.00%
170 Select_range 1354177 29.17% 0 0.00%
171 Select_full_join 39479 0.85% 0 0.00%
172 Select_full_range_join 4097 0.09% 0 0.00%
173 Select_range_check 0 0.00% 0 0.00%
174 The command summary table is built by extracting variables from
176 "STATUS_VARIABLES". The variables must be numeric and must match
177 the prefix given by the "cmd_filter" configuration variable. The
178 variables are then sorted by value descending and compared to the
179 last variable, as shown above. The percentage columns are
180 percentage of the total of all variables in the table, so you can
181 see the relative weight of the variables.
182 The example shows what you see if the prefix is "Select_". The
184 default prefix is "Com_". You can choose a prefix with the 's'
185 key.
186 It's rather like running SHOW VARIABLES LIKE "prefix%" with memory
188 and nice formatting.
189 Values are aggregated across all servers. The Pct columns are not
191 correctly aggregated across multiple servers. This is a known
192 limitation of the grouping algorithm that may be fixed in the
193 future.
194 D: InnoDB Deadlocks
196 This mode shows the transactions involved in the last InnoDB
197 deadlock. A second table shows the locks each transaction held and
198 waited for. A deadlock is caused by a cycle in the waits-for
199 graph, so there should be two locks held and one waited for unless
200 the deadlock information is truncated.
201 InnoDB puts deadlock information before some other information in
203 the SHOW INNODB STATUS output. If there are a lot of locks, the
204 deadlock information can grow very large, and there is a limit on
205 the size of the SHOW INNODB STATUS output. A large deadlock can
206 fill the entire output, or even be truncated, and prevent you from
207 seeing other information at all. If you are running innotop in
208 another mode, for example T mode, and suddenly you don't see
209 anything, you might want to check and see if a deadlock has wiped
210 out the data you need.
211 If it has, you can create a small deadlock to replace the large
213 one. Use the 'w' key to 'wipe' the large deadlock with a small
214 one. This will not work unless you have defined a deadlock table
215 for the connection (see "SERVER CONNECTIONS").
216 You can also configure innotop to automatically detect when a large
218 deadlock needs to be replaced with a small one (see
219 "auto_wipe_dl").
220 This mode displays the "deadlock_transactions" and "deadlock_locks"
222 tables by default.
223 F: InnoDB Foreign Key Errors
225 This mode shows the last InnoDB foreign key error information, such
226 as the table where it happened, when and who and what query caused
227 it, and so on.
228 InnoDB has a huge variety of foreign key error messages, and many
230 of them are just hard to parse. innotop doesn't always do the best
231 job here, but there's so much code devoted to parsing this messy,
232 unparseable output that innotop is likely never to be perfect in
233 this regard. If innotop doesn't show you what you need to see,
234 just look at the status text directly.
235 This mode displays the "fk_error" table by default.
237 I: InnoDB I/O Info
239 This mode shows InnoDB's I/O statistics, including the I/O threads,
240 pending I/O, file I/O miscellaneous, and log statistics. It
241 displays the "io_threads", "pending_io", "file_io_misc", and
242 "log_statistics" tables by default.
243 L: Locks
245 This mode shows information about current locks. At the moment
246 only InnoDB locks are supported, and by default you'll only see
247 locks for which transactions are waiting. This information comes
248 from the TRANSACTIONS section of the InnoDB status text. If you
249 have a very busy server, you may have frequent lock waits; it helps
250 to be able to see which tables and indexes are the "hot spot" for
251 locks. If your server is running pretty well, this mode should
252 show nothing.
253 You can configure MySQL and innotop to monitor not only locks for
255 which a transaction is waiting, but those currently held, too. You
256 can do this with the InnoDB Lock Monitor
257 (http://dev.mysql.com/doc/en/innodb-monitor.html
258 <http://dev.mysql.com/doc/en/innodb-monitor.html>). It's not
259 documented in the MySQL manual, but creating the lock monitor with
260 the following statement also affects the output of SHOW INNODB
261 STATUS, which innotop uses:
262 CREATE TABLE innodb_lock_monitor(a int) ENGINE=INNODB;
264 This causes InnoDB to print its output to the MySQL file every 16
266 seconds or so, as stated in the manual, but it also makes the
267 normal SHOW INNODB STATUS output include lock information, which
268 innotop can parse and display (that's the undocumented feature).
269 This means you can do what may have seemed impossible: to a limited
271 extent (InnoDB truncates some information in the output), you can
272 see which transaction holds the locks something else is waiting
273 for. You can also enable and disable the InnoDB Lock Monitor with
274 the key mappings in this mode.
275 This mode displays the "innodb_locks" table by default. Here's a
277 sample of the screen when one connection is waiting for locks
278 another connection holds:
279 _________________________________ InnoDB Locks __________________________
281 CXN ID Type Waiting Wait Active Mode DB Table Index
282 localhost 12 RECORD 1 00:10 00:10 X test t1 PRIMARY
283 localhost 12 TABLE 0 00:10 00:10 IX test t1
284 localhost 12 RECORD 1 00:10 00:10 X test t1 PRIMARY
285 localhost 11 TABLE 0 00:00 00:25 IX test t1
286 localhost 11 RECORD 0 00:00 00:25 X test t1 PRIMARY
287 You can see the first connection, ID 12, is waiting for a lock on
289 the PRIMARY key on test.t1, and has been waiting for 10 seconds.
290 The second connection isn't waiting, because the Waiting column is
291 0, but it holds locks on the same index. That tells you connection
292 11 is blocking connection 12.
293 M: Master/Slave Replication Status
295 This mode shows the output of SHOW SLAVE STATUS and SHOW MASTER
296 STATUS in three tables. The first two divide the slave's status
297 into SQL and I/O thread status, and the last shows master status.
298 Filters are applied to eliminate non-slave servers from the slave
299 tables, and non-master servers from the master table.
300 This mode displays the "slave_sql_status", "slave_io_status", and
302 "master_status" tables by default.
303 O: Open Tables
305 This section comes from MySQL's SHOW OPEN TABLES command. By
306 default it is filtered to show tables which are in use by one or
307 more queries, so you can get a quick look at which tables are
308 'hot'. You can use this to guess which tables might be locked
309 implicitly.
310 This mode displays the "open_tables" mode by default.
312 Q: Query List
314 This mode displays the output from SHOW FULL PROCESSLIST, much like
315 mytop's query list mode. This mode does not show InnoDB-related
316 information. This is probably one of the most useful modes for
317 general usage.
318 There is an informative header that shows general status
320 information about your server. You can toggle it on and off with
321 the 'h' key. By default, innotop hides inactive processes and its
322 own process. You can toggle these on and off with the 'i' and 'a'
323 keys.
324 You can EXPLAIN a query from this mode with the 'e' key. This
326 displays the query's full text, the results of EXPLAIN, and in
327 newer MySQL versions, even the optimized query resulting from
328 EXPLAIN EXTENDED. innotop also tries to rewrite certain queries to
329 make them EXPLAIN-able. For example, INSERT/SELECT statements are
330 rewritable.
331 This mode displays the "q_header" and "processlist" tables by
333 default.
334 R: InnoDB Row Operations and Semaphores
336 This mode shows InnoDB row operations, row operation miscellaneous,
337 semaphores, and information from the wait array. It displays the
338 "row_operations", "row_operation_misc", "semaphores", and
339 "wait_array" tables by default.
340 S: Variables & Status
342 This mode calculates statistics, such as queries per second, and
343 prints them out in several different styles. You can show absolute
344 values, or incremental values between ticks.
345 You can switch between the views by pressing a key. The 's' key
347 prints a single line each time the screen updates, in the style of
348 vmstat. The 'g' key changes the view to a graph of the same
349 numbers, sort of like tload. The 'v' key changes the view to a
350 pivoted table of variable names on the left, with successive
351 updates scrolling across the screen from left to right. You can
352 choose how many updates to put on the screen with the
353 "num_status_sets" configuration variable.
354 Headers may be abbreviated to fit on the screen in interactive
356 operation. You choose which variables to display with the 'c' key,
357 which selects from predefined sets, or lets you create your own
358 sets. You can edit the current set with the 'e' key.
359 This mode doesn't really display any tables like other modes.
361 Instead, it uses a table definition to extract and format the data,
362 but it then transforms the result in special ways before outputting
363 it. It uses the "var_status" table definition for this.
364 T: InnoDB Transactions
366 This mode shows transactions from the InnoDB monitor's output, in
367 top-like format. This mode is the reason I wrote innotop.
368 You can kill queries or processes with the 'k' and 'x' keys, and
370 EXPLAIN a query with the 'e' or 'f' keys. InnoDB doesn't print the
371 full query in transactions, so explaining may not work right if the
372 query is truncated.
373 The informational header can be toggled on and off with the 'h'
375 key. By default, innotop hides inactive transactions and its own
376 transaction. You can toggle this on and off with the 'i' and 'a'
377 keys.
378 This mode displays the "t_header" and "innodb_transactions" tables
380 by default.
381
383 The first line innotop displays is a "status bar" of sorts. What it
384 contains depends on the mode you're in, and what servers you're
385 monitoring. The first few words are always the innotop mode, such as
386 "InnoDB Txns" for T mode, followed by a reminder to press '?' for help
387 at any time.
388 ONE SERVER
390 The simplest case is when you're monitoring a single server. In this
391 case, the name of the connection is next on the status line. This is
392 the name you gave when you created the connection -- most likely the
393 MySQL server's hostname. This is followed by the server's uptime.
394 If you're in an InnoDB mode, such as T or B, the next word is "InnoDB"
396 followed by some information about the SHOW INNODB STATUS output used
397 to render the screen. The first word is the number of seconds since
398 the last SHOW INNODB STATUS, which InnoDB uses to calculate some per-
399 second statistics. The next is a smiley face indicating whether the
400 InnoDB output is truncated. If the smiley face is a :-), all is well;
401 there is no truncation. A :^| means the transaction list is so long,
402 InnoDB has only printed out some of the transactions. Finally, a frown
403 :-( means the output is incomplete, which is probably due to a deadlock
404 printing too much lock information (see "D: InnoDB Deadlocks").
405 The next two words indicate the server's queries per second (QPS) and
407 how many threads (connections) exist. Finally, the server's version
408 number is the last thing on the line.
409 MULTIPLE SERVERS
411 If you are monitoring multiple servers (see "SERVER CONNECTIONS"), the
412 status line does not show any details about individual servers.
413 Instead, it shows the names of the connections that are active. Again,
414 these are connection names you specified, which are likely to be the
415 server's hostname. A connection that has an error is prefixed with an
416 exclamation point.
417 If you are monitoring a group of servers (see "SERVER GROUPS"), the
419 status line shows the name of the group. If any connection in the
420 group has an error, the group's name is followed by the fraction of the
421 connections that don't have errors.
422 See "ERROR HANDLING" for more details about innotop's error handling.
424 MONITORING A FILE
426 If you give a filename on the command line, innotop will not connect to
427 ANY servers at all. It will watch the specified file for InnoDB status
428 output and use that as its data source. It will always show a single
429 connection called 'file'. And since it can't connect to a server, it
430 can't determine how long the server it's monitoring has been up; so it
431 calculates the server's uptime as time since innotop started running.
432
434 While innotop is primarily a monitor that lets you watch and analyze
435 your servers, it can also send commands to servers. The most
436 frequently useful commands are killing queries and stopping or starting
437 slaves.
438 You can kill a connection, or in newer versions of MySQL kill a query
440 but not a connection, from "Q: Query List" and "T: InnoDB Transactions"
441 modes. Press 'k' to issue a KILL command, or 'x' to issue a KILL QUERY
442 command. innotop will prompt you for the server and/or connection ID
443 to kill (innotop does not prompt you if there is only one possible
444 choice for any input). innotop pre-selects the longest-running query,
445 or the oldest connection. Confirm the command with 'y'.
446 In "Slave Replication Status"" in "M: Master mode, you can start and
448 stop slaves with the 'a' and 'o' keys, respectively. You can send
449 these commands to many slaves at once. innotop fills in a default
450 command of START SLAVE or STOP SLAVE for you, but you can actually edit
451 the command and send anything you wish, such as SET GLOBAL
452 SQL_SLAVE_SKIP_COUNTER=1 to make the slave skip one binlog event when
453 it starts.
454 You can also ask innotop to calculate the earliest binlog in use by any
456 slave and issue a PURGE MASTER LOGS on the master. Use the 'b' key for
457 this. innotop will prompt you for a master to run the command on, then
458 prompt you for the connection names of that master's slaves (there is
459 no way for innotop to determine this reliably itself). innotop will
460 find the minimum binlog in use by these slave connections and suggest
461 it as the argument to PURGE MASTER LOGS.
462
464 When you create a server connection, innotop asks you for a series of
465 inputs, as follows:
466 DSN A DSN is a Data Source Name, which is the initial argument passed
468 to the DBI module for connecting to a server. It is usually of the
469 form
470 DBI:mysql:;mysql_read_default_group=mysql;host=HOSTNAME
472 Since this DSN is passed to the DBD::mysql driver, you should read
474 the driver's documentation at
475 "/search.cpan.org/dist/DBD-mysql/lib/DBD/mysql.pm"" in "http: for
476 the exact details on all the options you can pass the driver in the
477 DSN. You can read more about DBI at <http://dbi.perl.org/docs/>,
478 and especially at <http://search.cpan.org/~timb/DBI/DBI.pm>.
479 The mysql_read_default_group=mysql option lets the DBD driver read
481 your MySQL options files, such as ~/.my.cnf on UNIX-ish systems.
482 You can use this to avoid specifying a username or password for the
483 connection.
484 InnoDB Deadlock Table
486 This optional item tells innotop a table name it can use to
487 deliberately create a small deadlock (see "D: InnoDB Deadlocks").
488 If you specify this option, you just need to be sure the table
489 doesn't exist, and that innotop can create and drop the table with
490 the InnoDB storage engine. You can safely omit or just accept the
491 default if you don't intend to use this.
492 Username
494 innotop will ask you if you want to specify a username. If you say
495 'y', it will then prompt you for a user name. If you have a MySQL
496 option file that specifies your username, you don't have to specify
497 a username.
498 The username defaults to your login name on the system you're
500 running innotop on.
501 Password
503 innotop will ask you if you want to specify a password. Like the
504 username, the password is optional, but there's an additional
505 prompt that asks if you want to save the password in the innotop
506 configuration file. If you don't save it in the configuration
507 file, innotop will prompt you for a password each time it starts.
508 Passwords in the innotop configuration file are saved in plain
509 text, not encrypted in any way.
510 Once you finish answering these questions, you should be connected to a
512 server. But innotop isn't limited to monitoring a single server; you
513 can define many server connections and switch between them by pressing
514 the '@' key. See "SWITCHING BETWEEN CONNECTIONS".
515 To create a new connection, press the '@' key and type the name of the
517 new connection, then follow the steps given above.
518
520 If you have multiple MySQL instances, you can put them into named
521 groups, such as 'all', 'masters', and 'slaves', which innotop can
522 monitor all together.
523 You can choose which group to monitor with the '#' key, and you can
525 press the TAB key to switch to the next group. If you're not currently
526 monitoring a group, pressing TAB selects the first group.
527 To create a group, press the '#' key and type the name of your new
529 group, then type the names of the connections you want the group to
530 contain.
531
533 innotop lets you quickly switch which servers you're monitoring. The
534 most basic way is by pressing the '@' key and typing the name(s) of the
535 connection(s) you want to use. This setting is per-mode, so you can
536 monitor different connections in each mode, and innotop remembers which
537 connections you choose.
538 You can quickly switch to the 'next' connection in alphabetical order
540 with the 'n' key. If you're monitoring a server group (see "SERVER
541 GROUPS") this will switch to the first connection.
542 You can also type many connection names, and innotop will fetch and
544 display data from them all. Just separate the connection names with
545 spaces, for example "server1 server2." Again, if you type the name of
546 a connection that doesn't exist, innotop will prompt you for connection
547 information and create the connection.
548 Another way to monitor multiple connections at once is with server
550 groups. You can use the TAB key to switch to the 'next' group in
551 alphabetical order, or if you're not monitoring any groups, TAB will
552 switch to the first group.
553 innotop does not fetch data in parallel from connections, so if you are
555 monitoring a large group or many connections, you may notice increased
556 delay between ticks.
557 When you monitor more than one connection, innotop's status bar
559 changes. See "INNOTOP STATUS".
560
562 Error handling is not that important when monitoring a single
563 connection, but is crucial when you have many active connections. A
564 crashed server or lost connection should not crash innotop. As a
565 result, innotop will continue to run even when there is an error; it
566 just won't display any information from the connection that had an
567 error. Because of this, innotop's behavior might confuse you. It's a
568 feature, not a bug!
569 innotop does not continue to query connections that have errors,
571 because they may slow innotop and make it hard to use, especially if
572 the error is a problem connecting and causes a long time-out. Instead,
573 innotop retries the connection occasionally to see if the error still
574 exists. If so, it will wait until some point in the future. The wait
575 time increases in ticks as the Fibonacci series, so it tries less
576 frequently as time passes.
577 Since errors might only happen in certain modes because of the SQL
579 commands issued in those modes, innotop keeps track of which mode
580 caused the error. If you switch to a different mode, innotop will
581 retry the connection instead of waiting.
582 By default innotop will display the problem in red text at the bottom
584 of the first table on the screen. You can disable this behavior with
585 the "show_cxn_errors_in_tbl" configuration option, which is enabled by
586 default. If the "debug" option is enabled, innotop will display the
587 error at the bottom of every table, not just the first. And if
588 "show_cxn_errors" is enabled, innotop will print the error text to
589 STDOUT as well. Error messages might only display in the mode that
590 caused the error, depending on the mode and whether innotop is avoiding
591 querying that connection.
592
594 You can run innotop in non-interactive mode, in which case it is
595 entirely controlled from the configuration file and command-line
596 options. To start innotop in non-interactive mode, give the
597 L"<--nonint"> command-line option. This changes innotop's behavior in
598 the following ways:
599 · Certain Perl modules are not loaded. Term::Readline is not loaded,
601 since innotop doesn't prompt interactively. Term::ANSIColor and
602 Win32::Console::ANSI modules are not loaded. Term::ReadKey is
603 still used, since innotop may have to prompt for connection
604 passwords when starting up.
605 · innotop does not clear the screen after each tick.
607 · innotop does not persist any changes to the configuration file.
609 · If "--count" is given and innotop is in incremental mode (see
611 "status_inc" and "--inc"), innotop actually refreshes one more time
612 than specified so it can print incremental statistics. This
613 suppresses output during the first tick, so innotop may appear to
614 hang.
615 · innotop only displays the first table in each mode. This is so the
617 output can be easily processed with other command-line utilities
618 such as awk and sed. To change which tables display in each mode,
619 see "TABLES". Since "Q: Query List" mode is so important, innotop
620 automatically disables the "q_header" table. This ensures you'll
621 see the "processlist" table, even if you have innotop configured to
622 show the q_header table during interactive operation. Similarly,
623 in "T: InnoDB Transactions" mode, the "t_header" table is
624 suppressed so you see only the "innodb_transactions" table.
625 · All output is tab-separated instead of being column-aligned with
627 whitespace, and innotop prints the full contents of each table
628 instead of only printing one screenful at a time.
629 · innotop only prints column headers once instead of every tick (see
631 "hide_hdr"). innotop does not print table captions (see
632 "display_table_captions"). innotop ensures there are no empty
633 lines in the output.
634 · innotop does not honor the "shorten" transformation, which normally
636 shortens some numbers to human-readable formats.
637 · innotop does not print a status line (see "INNOTOP STATUS").
639
641 Nearly everything about innotop is configurable. Most things are
642 possible to change with built-in commands, but you can also edit the
643 configuration file.
644 While running innotop, press the '$' key to bring up the configuration
646 editing dialog. Press another key to select the type of data you want
647 to edit:
648 S: Statement Sleep Times
650 Edits SQL statement sleep delays, which make innotop pause for the
651 specified amount of time after executing a statement. See "SQL
652 STATEMENTS" for a definition of each statement and what it does.
653 By default innotop does not delay after any statements.
654 This feature is included so you can customize the side-effects
656 caused by monitoring your server. You may not see any effects, but
657 some innotop users have noticed that certain MySQL versions under
658 very high load with InnoDB enabled take longer than usual to
659 execute SHOW GLOBAL STATUS. If innotop calls SHOW FULL PROCESSLIST
660 immediately afterward, the processlist contains more queries than
661 the machine actually averages at any given moment. Configuring
662 innotop to pause briefly after calling SHOW GLOBAL STATUS
663 alleviates this effect.
664 Sleep times are stored in the "stmt_sleep_times" section of the
666 configuration file. Fractional-second sleeps are supported,
667 subject to your hardware's limitations.
668 c: Edit Columns
670 Starts the table editor on one of the displayed tables. See "TABLE
671 EDITOR". An alternative way to start the table editor without
672 entering the configuration dialog is with the '^' key.
673 g: General Configuration
675 Starts the configuration editor to edit global and mode-specific
676 configuration variables (see "MODES"). innotop prompts you to
677 choose a variable from among the global and mode-specific ones
678 depending on the current mode.
679 k: Row-Coloring Rules
681 Starts the row-coloring rules editor on one of the displayed
682 table(s). See "COLORS" for details.
683 p: Manage Plugins
685 Starts the plugin configuration editor. See "PLUGINS" for details.
686 s: Server Groups
688 Lets you create and edit server groups. See "SERVER GROUPS".
689 t: Choose Displayed Tables
691 Lets you choose which tables to display in this mode. See "MODES"
692 and "TABLES".
693
695 innotop's default configuration file location is in $HOME/.innotop, but
696 can be overridden with the "--config" command-line option. You can
697 edit it by hand safely. innotop reads the configuration file when it
698 starts, and writes it out again when it exits, so any changes you make
699 while innotop is running will be lost.
700 innotop doesn't store its entire configuration in the configuration
702 file. It has a huge set of default configuration that it holds only in
703 memory, and the configuration file only overrides these defaults. When
704 you customize a default setting, innotop notices, and then stores the
705 customizations into the file. This keeps the file size down, makes it
706 easier to edit, and makes upgrades easier.
707 A configuration file can be made read-only. See "readonly".
709 The configuration file is arranged into sections like an INI file.
711 Each section begins with [section-name] and ends with [/section-name].
712 Each section's entries have a different syntax depending on the data
713 they need to store. You can put comments in the file; any line that
714 begins with a # character is a comment. innotop will not read the
715 comments, so it won't write them back out to the file when it exits.
716 Comments in read-only configuration files are still useful, though.
717 The first line in the file is innotop's version number. This lets
719 innotop notice when the file format is not backwards-compatible, and
720 upgrade smoothly without destroying your customized configuration.
721 The following list describes each section of the configuration file and
723 the data it contains:
724 general
726 The 'general' section contains global configuration variables and
727 variables that may be mode-specific, but don't belong in any other
728 section. The syntax is a simple key=value list. innotop writes a
729 comment above each value to help you edit the file by hand.
730 S_func
732 Controls S mode presentation (see "S: Variables & Status"). If
733 g, values are graphed; if s, values are like vmstat; if p,
734 values are in a pivoted table.
735 S_set
737 Specifies which set of variables to display in "S: Variables &
738 Status" mode. See "VARIABLE SETS".
739 auto_wipe_dl
741 Instructs innotop to automatically wipe large deadlocks when it
742 notices them. When this happens you may notice a slight delay.
743 At the next tick, you will usually see the information that was
744 being truncated by the large deadlock.
745 charset
747 Specifies what kind of characters to allow through the
748 "no_ctrl_char" transformation. This keeps non-printable
749 characters from confusing a terminal when you monitor queries
750 that contain binary data, such as images.
751 The default is 'ascii', which considers anything outside normal
753 ASCII to be a control character. The other allowable values
754 are 'unicode' and 'none'. 'none' considers every character a
755 control character, which can be useful for collapsing ALL text
756 fields in queries.
757 cmd_filter
759 This is the prefix that filters variables in "C: Command
760 Summary" mode.
761 color
763 Whether terminal coloring is permitted.
764 cxn_timeout
766 On MySQL versions 4.0.3 and newer, this variable is used to set
767 the connection's timeout, so MySQL doesn't close the connection
768 if it is not used for a while. This might happen because a
769 connection isn't monitored in a particular mode, for example.
770 debug
772 This option enables more verbose errors and makes innotop more
773 strict in some places. It can help in debugging filters and
774 other user-defined code. It also makes innotop write a lot of
775 information to "debugfile" when there is a crash.
776 debugfile
778 A file to which innotop will write information when there is a
779 crash. See "FILES".
780 display_table_captions
782 innotop displays a table caption above most tables. This
783 variable suppresses or shows captions on all tables globally.
784 Some tables are configured with the hide_caption property,
785 which overrides this.
786 global
788 Whether to show GLOBAL variables and status. innotop only
789 tries to do this on servers which support the GLOBAL option to
790 SHOW VARIABLES and SHOW STATUS. In some MySQL versions, you
791 need certain privileges to do this; if you don't have them,
792 innotop will not be able to fetch any variable and status data.
793 This configuration variable lets you run innotop and fetch what
794 data you can even without the elevated privileges.
795 I can no longer find or reproduce the situation where GLOBAL
797 wasn't allowed, but I know there was one.
798 graph_char
800 Defines the character to use when drawing graphs in "S:
801 Variables & Status" mode.
802 header_highlight
804 Defines how to highlight column headers. This only works if
805 Term::ANSIColor is available. Valid values are 'bold' and
806 'underline'.
807 hide_hdr
809 Hides column headers globally.
810 interval
812 The interval at which innotop will refresh its data (ticks).
813 The interval is implemented as a sleep time between ticks, so
814 the true interval will vary depending on how long it takes
815 innotop to fetch and render data.
816 This variable accepts fractions of a second.
818 mode
820 The mode in which innotop should start. Allowable arguments
821 are the same as the key presses that select a mode
822 interactively. See "MODES".
823 num_digits
825 How many digits to show in fractional numbers and percents.
826 This variable's range is between 0 and 9 and can be set
827 directly from "S: Variables & Status" mode with the '+' and '-'
828 keys. It is used in the "set_precision", "shorten", and
829 "percent" transformations.
830 num_status_sets
832 Controls how many sets of status variables to display in
833 pivoted "S: Variables & Status" mode. It also controls the
834 number of old sets of variables innotop keeps in its memory, so
835 the larger this variable is, the more memory innotop uses.
836 plugin_dir
838 Specifies where plugins can be found. By default, innotop
839 stores plugins in the 'plugins' subdirectory of your innotop
840 configuration directory.
841 readonly
843 Whether the configuration file is readonly. This cannot be set
844 interactively, because it would prevent itself from being
845 written to the configuration file.
846 show_cxn_errors
848 Makes innotop print connection errors to STDOUT. See "ERROR
849 HANDLING".
850 show_cxn_errors_in_tbl
852 Makes innotop display connection errors as rows in the first
853 table on screen. See "ERROR HANDLING".
854 show_percent
856 Adds a '%' character after the value returned by the "percent"
857 transformation.
858 show_statusbar
860 Controls whether to show the status bar in the display. See
861 "INNOTOP STATUS".
862 skip_innodb
864 Disables fetching SHOW INNODB STATUS, in case your server(s) do
865 not have InnoDB enabled and you don't want innotop to try to
866 fetch it. This can also be useful when you don't have the
867 SUPER privilege, required to run SHOW INNODB STATUS.
868 status_inc
870 Whether to show absolute or incremental values for status
871 variables. Incremental values are calculated as an offset from
872 the last value innotop saw for that variable. This is a global
873 setting, but will probably become mode-specific at some point.
874 Right now it is honored a bit inconsistently; some modes don't
875 pay attention to it.
876 plugins
878 This section holds a list of package names of active plugins. If
879 the plugin exists, innotop will activate it. See "PLUGINS" for
880 more information.
881 filters
883 This section holds user-defined filters (see "FILTERS"). Each line
884 is in the format filter_name=text='filter text' tbls='table list'.
885 The filter text is the text of the subroutine's code. The table
887 list is a list of tables to which the filter can apply. By
888 default, user-defined filters apply to the table for which they
889 were created, but you can manually override that by editing the
890 definition in the configuration file.
891 active_filters
893 This section stores which filters are active on each table. Each
894 line is in the format table_name=filter_list.
895 tbl_meta
897 This section stores user-defined or user-customized columns (see
898 "COLUMNS"). Each line is in the format col_name=properties, where
899 the properties are a name=quoted-value list.
900 connections
902 This section holds the server connections you have defined. Each
903 line is in the format name=properties, where the properties are a
904 name=value list. The properties are self-explanatory, and the only
905 one that is treated specially is 'pass' which is only present if
906 'savepass' is set. See "SERVER CONNECTIONS".
907 active_connections
909 This section holds a list of which connections are active in each
910 mode. Each line is in the format mode_name=connection_list.
911 server_groups
913 This section holds server groups. Each line is in the format
914 name=connection_list. See "SERVER GROUPS".
915 active_server_groups
917 This section holds a list of which server group is active in each
918 mode. Each line is in the format mode_name=server_group.
919 max_values_seen
921 This section holds the maximum values seen for variables. This is
922 used to scale the graphs in "S: Variables & Status" mode. Each
923 line is in the format name=value.
924 active_columns
926 This section holds table column lists. Each line is in the format
927 tbl_name=column_list. See "COLUMNS".
928 sort_cols
930 This section holds the sort definition. Each line is in the format
931 tbl_name=column_list. If a column is prefixed with '-', that
932 column sorts descending. See "SORTING".
933 visible_tables
935 This section defines which tables are visible in each mode. Each
936 line is in the format mode_name=table_list. See "TABLES".
937 varsets
939 This section defines variable sets for use in "S: Status &
940 Variables" mode. Each line is in the format name=variable_list.
941 See "VARIABLE SETS".
942 colors
944 This section defines colorization rules. Each line is in the
945 format tbl_name=property_list. See "COLORS".
946 stmt_sleep_times
948 This section contains statement sleep times. Each line is in the
949 format statement_name=sleep_time. See "S: Statement Sleep Times".
950 group_by
952 This section contains column lists for table group_by expressions.
953 Each line is in the format tbl_name=column_list. See "GROUPING".
954
956 You can customize innotop a great deal. For example, you can:
957 · Choose which tables to display, and in what order.
959 · Choose which columns are in those tables, and create new columns.
961 · Filter which rows display with built-in filters, user-defined
963 filters, and quick-filters.
964 · Sort the rows to put important data first or group together related
966 rows.
967 · Highlight rows with color.
969 · Customize the alignment, width, and formatting of columns, and
971 apply transformations to columns to extract parts of their values
972 or format the values as you wish (for example, shortening large
973 numbers to familiar units).
974 · Design your own expressions to extract and combine data as you
976 need. This gives you unlimited flexibility.
977 All these and more are explained in the following sections.
979 TABLES
981 A table is what you'd expect: a collection of columns. It also has
982 some other properties, such as a caption. Filters, sorting rules, and
983 colorization rules belong to tables and are covered in later sections.
984 Internally, table meta-data is defined in a data structure called
986 %tbl_meta. This hash holds all built-in table definitions, which
987 contain a lot of default instructions to innotop. The meta-data
988 includes the caption, a list of columns the user has customized, a list
989 of columns, a list of visible columns, a list of filters, color rules,
990 a sort-column list, sort direction, and some information about the
991 table's data sources. Most of this is customizable via the table
992 editor (see "TABLE EDITOR").
993 You can choose which tables to show by pressing the '$' key. See
995 "MODES" and "TABLES".
996 The table life-cycle is as follows:
998 · Each table begins with a data source, which is an array of hashes.
1000 See below for details on data sources.
1001 · Each element of the data source becomes a row in the final table.
1003 · For each element in the data source, innotop extracts values from
1005 the source and creates a row. This row is another hash, which
1006 later steps will refer to as $set. The values innotop extracts are
1007 determined by the table's columns. Each column has an extraction
1008 subroutine, compiled from an expression (see "EXPRESSIONS"). The
1009 resulting row is a hash whose keys are named the same as the column
1010 name.
1011 · innotop filters the rows, removing those that don't need to be
1013 displayed. See "FILTERS".
1014 · innotop sorts the rows. See "SORTING".
1016 · innotop groups the rows together, if specified. See "GROUPING".
1018 · innotop colorizes the rows. See "COLORS".
1020 · innotop transforms the column values in each row. See
1022 "TRANSFORMATIONS".
1023 · innotop optionally pivots the rows (see "PIVOTING"), then filters
1025 and sorts them.
1026 · innotop formats and justifies the rows as a table. During this
1028 step, innotop applies further formatting to the column values,
1029 including alignment, maximum and minimum widths. innotop also does
1030 final error checking to ensure there are no crashes due to
1031 undefined values. innotop then adds a caption if specified, and
1032 the table is ready to print.
1033 The lifecycle is slightly different if the table is pivoted, as noted
1035 above. To clarify, if the table is pivoted, the process is extract,
1036 group, transform, pivot, filter, sort, create. If it's not pivoted,
1037 the process is extract, filter, sort, group, color, transform, create.
1038 This slightly convoluted process doesn't map all that well to SQL, but
1039 pivoting complicates things pretty thoroughly. Roughly speaking,
1040 filtering and sorting happen as late as needed to effect the final
1041 result as you might expect, but as early as possible for efficiency.
1042 Each built-in table is described below:
1044 adaptive_hash_index
1046 Displays data about InnoDB's adaptive hash index. Data source:
1047 "STATUS_VARIABLES".
1048 buffer_pool
1050 Displays data about InnoDB's buffer pool. Data source:
1051 "STATUS_VARIABLES".
1052 cmd_summary
1054 Displays weighted status variables. Data source:
1055 "STATUS_VARIABLES".
1056 deadlock_locks
1058 Shows which locks were held and waited for by the last detected
1059 deadlock. Data source: "DEADLOCK_LOCKS".
1060 deadlock_transactions
1062 Shows transactions involved in the last detected deadlock. Data
1063 source: "DEADLOCK_TRANSACTIONS".
1064 explain
1066 Shows the output of EXPLAIN. Data source: "EXPLAIN".
1067 file_io_misc
1069 Displays data about InnoDB's file and I/O operations. Data source:
1070 "STATUS_VARIABLES".
1071 fk_error
1073 Displays various data about InnoDB's last foreign key error. Data
1074 source: "STATUS_VARIABLES".
1075 innodb_locks
1077 Displays InnoDB locks. Data source: "INNODB_LOCKS".
1078 innodb_transactions
1080 Displays data about InnoDB's current transactions. Data source:
1081 "INNODB_TRANSACTIONS".
1082 insert_buffers
1084 Displays data about InnoDB's insert buffer. Data source:
1085 "STATUS_VARIABLES".
1086 io_threads
1088 Displays data about InnoDB's I/O threads. Data source:
1089 "IO_THREADS".
1090 log_statistics
1092 Displays data about InnoDB's logging system. Data source:
1093 "STATUS_VARIABLES".
1094 master_status
1096 Displays replication master status. Data source:
1097 "STATUS_VARIABLES".
1098 open_tables
1100 Displays open tables. Data source: "OPEN_TABLES".
1101 page_statistics
1103 Displays InnoDB page statistics. Data source: "STATUS_VARIABLES".
1104 pending_io
1106 Displays InnoDB pending I/O operations. Data source:
1107 "STATUS_VARIABLES".
1108 processlist
1110 Displays current MySQL processes (threads/connections). Data
1111 source: "PROCESSLIST".
1112 q_header
1114 Displays various status values. Data source: "STATUS_VARIABLES".
1115 row_operation_misc
1117 Displays data about InnoDB's row operations. Data source:
1118 "STATUS_VARIABLES".
1119 row_operations
1121 Displays data about InnoDB's row operations. Data source:
1122 "STATUS_VARIABLES".
1123 semaphores
1125 Displays data about InnoDB's semaphores and mutexes. Data source:
1126 "STATUS_VARIABLES".
1127 slave_io_status
1129 Displays data about the slave I/O thread. Data source:
1130 "STATUS_VARIABLES".
1131 slave_sql_status
1133 Displays data about the slave SQL thread. Data source:
1134 "STATUS_VARIABLES".
1135 t_header
1137 Displays various InnoDB status values. Data source:
1138 "STATUS_VARIABLES".
1139 var_status
1141 Displays user-configurable data. Data source: "STATUS_VARIABLES".
1142 wait_array
1144 Displays data about InnoDB's OS wait array. Data source:
1145 "OS_WAIT_ARRAY".
1146 COLUMNS
1148 Columns belong to tables. You can choose a table's columns by pressing
1149 the '^' key, which starts the "TABLE EDITOR" and lets you choose and
1150 edit columns. Pressing 'e' from within the table editor lets you edit
1151 the column's properties:
1152 · hdr: a column header. This appears in the first row of the table.
1154 · just: justification. '-' means left-justified and '' means right-
1156 justified, just as with printf formatting codes (not a
1157 coincidence).
1158 · dec: whether to further align the column on the decimal point.
1160 · num: whether the column is numeric. This affects how values are
1162 sorted (lexically or numerically).
1163 · label: a small note about the column, which appears in dialogs that
1165 help the user choose columns.
1166 · src: an expression that innotop uses to extract the column's data
1168 from its source (see "DATA SOURCES"). See "EXPRESSIONS" for more
1169 on expressions.
1170 · minw: specifies a minimum display width. This helps stabilize the
1172 display, which makes it easier to read if the data is changing
1173 frequently.
1174 · maxw: similar to minw.
1176 · trans: a list of column transformations. See "TRANSFORMATIONS".
1178 · agg: an aggregate function. See "GROUPING". The default is
1180 "first".
1181 · aggonly: controls whether the column only shows when grouping is
1183 enabled on the table (see "GROUPING"). By default, this is
1184 disabled. This means columns will always be shown by default,
1185 whether grouping is enabled or not. If a column's aggonly is set
1186 true, the column will appear when you toggle grouping on the table.
1187 Several columns are set this way, such as the count column on
1188 "processlist" and "innodb_transactions", so you don't see a count
1189 when the grouping isn't enabled, but you do when it is.
1190 FILTERS
1192 Filters remove rows from the display. They behave much like a WHERE
1193 clause in SQL. innotop has several built-in filters, which remove
1194 irrelevant information like inactive queries, but you can define your
1195 own as well. innotop also lets you create quick-filters, which do not
1196 get saved to the configuration file, and are just an easy way to
1197 quickly view only some rows.
1198 You can enable or disable a filter on any table. Press the '%' key
1200 (mnemonic: % looks kind of like a line being filtered between two
1201 circles) and choose which table you want to filter, if asked. You'll
1202 then see a list of possible filters and a list of filters currently
1203 enabled for that table. Type the names of filters you want to apply
1204 and press Enter.
1205 USER-DEFINED FILTERS
1207 If you type a name that doesn't exist, innotop will prompt you to
1209 create the filter. Filters are easy to create if you know Perl, and
1210 not hard if you don't. What you're doing is creating a subroutine that
1211 returns true if the row should be displayed. The row is a hash
1212 reference passed to your subroutine as $set.
1213 For example, imagine you want to filter the processlist table so you
1215 only see queries that have been running more than five minutes. Type a
1216 new name for your filter, and when prompted for the subroutine body,
1217 press TAB to initiate your terminal's auto-completion. You'll see the
1218 names of the columns in the "processlist" table (innotop generally
1219 tries to help you with auto-completion lists). You want to filter on
1220 the 'time' column. Type the text "$set->{time} > 300" to return true
1221 when the query is more than five minutes old. That's all you need to
1222 do.
1223 In other words, the code you're typing is surrounded by an implicit
1225 context, which looks like this:
1226 sub filter {
1228 my ( $set ) = @_;
1229 # YOUR CODE HERE
1230 }
1231 If your filter doesn't work, or if something else suddenly behaves
1233 differently, you might have made an error in your filter, and innotop
1234 is silently catching the error. Try enabling "debug" to make innotop
1235 throw an error instead.
1236 QUICK-FILTERS
1238 innotop's quick-filters are a shortcut to create a temporary filter
1240 that doesn't persist when you restart innotop. To create a quick-
1241 filter, press the '/' key. innotop will prompt you for the column name
1242 and filter text. Again, you can use auto-completion on column names.
1243 The filter text can be just the text you want to "search for." For
1244 example, to filter the "processlist" table on queries that refer to the
1245 products table, type '/' and then 'info product'.
1246 The filter text can actually be any Perl regular expression, but of
1248 course a literal string like 'product' works fine as a regular
1249 expression.
1250 Behind the scenes innotop compiles the quick-filter into a specially
1252 tagged filter that is otherwise like any other filter. It just isn't
1253 saved to the configuration file.
1254 To clear quick-filters, press the '\' key and innotop will clear them
1256 all at once.
1257 SORTING
1259 innotop has sensible built-in defaults to sort the most important rows
1260 to the top of the table. Like anything else in innotop, you can
1261 customize how any table is sorted.
1262 To start the sort dialog, start the "TABLE EDITOR" with the '^' key,
1264 choose a table if necessary, and press the 's' key. You'll see a list
1265 of columns you can use in the sort expression and the current sort
1266 expression, if any. Enter a list of columns by which you want to sort
1267 and press Enter. If you want to reverse sort, prefix the column name
1268 with a minus sign. For example, if you want to sort by column a
1269 ascending, then column b descending, type 'a -b'. You can also
1270 explicitly add a + in front of columns you want to sort ascending, but
1271 it's not required.
1272 Some modes have keys mapped to open this dialog directly, and to
1274 quickly reverse sort direction. Press '?' as usual to see which keys
1275 are mapped in any mode.
1276 GROUPING
1278 innotop can group, or aggregate, rows together (I use the terms
1279 interchangeably). This is quite similar to an SQL GROUP BY clause.
1280 You can specify to group on certain columns, or if you don't specify
1281 any, the entire set of rows is treated as one group. This is quite
1282 like SQL so far, but unlike SQL, you can also select un-grouped
1283 columns. innotop actually aggregates every column. If you don't
1284 explicitly specify a grouping function, the default is 'first'. This
1285 is basically a convenience so you don't have to specify an aggregate
1286 function for every column you want in the result.
1287 You can quickly toggle grouping on a table with the '=' key, which
1289 toggles its aggregate property. This property doesn't persist to the
1290 config file.
1291 The columns by which the table is grouped are specified in its group_by
1293 property. When you turn grouping on, innotop places the group_by
1294 columns at the far left of the table, even if they're not supposed to
1295 be visible. The rest of the visible columns appear in order after
1296 them.
1297 Two tables have default group_by lists and a count column built in:
1299 "processlist" and "innodb_transactions". The grouping is by connection
1300 and status, so you can quickly see how many queries or transactions are
1301 in a given status on each server you're monitoring. The time columns
1302 are aggregated as a sum; other columns are left at the default 'first'
1303 aggregation.
1304 By default, the table shown in "S: Variables & Status" mode also uses
1306 grouping so you can monitor variables and status across many servers.
1307 The default aggregation function in this mode is 'avg'.
1308 Valid grouping functions are defined in the %agg_funcs hash. They
1310 include
1311 first
1313 Returns the first element in the group.
1314 count
1316 Returns the number of elements in the group, including undefined
1317 elements, much like SQL's COUNT(*).
1318 avg Returns the average of defined elements in the group.
1320 sum Returns the sum of elements in the group.
1322 Here's an example of grouping at work. Suppose you have a very busy
1324 server with hundreds of open connections, and you want to see how many
1325 connections are in what status. Using the built-in grouping rules, you
1326 can press 'Q' to enter "Q: Query List" mode. Press '=' to toggle
1327 grouping (if necessary, select the "processlist" table when prompted).
1328 Your display might now look like the following:
1330 Query List (? for help) localhost, 32:33, 0.11 QPS, 1 thd, 5.0.38-log
1332 CXN Cmd Cnt ID User Host Time Query
1334 localhost Query 49 12933 webusr localhost 19:38 SELECT * FROM
1335 localhost Sending Da 23 2383 webusr localhost 12:43 SELECT col1,
1336 localhost Sleep 120 140 webusr localhost 5:18:12
1337 localhost Statistics 12 19213 webusr localhost 01:19 SELECT * FROM
1338 That's actually quite a worrisome picture. You've got a lot of idle
1340 connections (Sleep), and some connections executing queries (Query and
1341 Sending Data). That's okay, but you also have a lot in Statistics
1342 status, collectively spending over a minute. That means the query
1343 optimizer is having a really hard time optimizing your statements.
1344 Something is wrong; it should normally take milliseconds to optimize
1345 queries. You might not have seen this pattern if you didn't look at
1346 your connections in aggregate. (This is a made-up example, but it can
1347 happen in real life).
1348 PIVOTING
1350 innotop can pivot a table for more compact display, similar to a Pivot
1351 Table in a spreadsheet (also known as a crosstab). Pivoting a table
1352 makes columns into rows. Assume you start with this table:
1353 foo bar
1355 === ===
1356 1 3
1357 2 4
1358 After pivoting, the table will look like this:
1360 name set0 set1
1362 ==== ==== ====
1363 foo 1 2
1364 bar 3 4
1365 To get reasonable results, you might need to group as well as pivoting.
1367 innotop currently does this for "S: Variables & Status" mode.
1368 COLORS
1370 By default, innotop highlights rows with color so you can see at a
1371 glance which rows are more important. You can customize the
1372 colorization rules and add your own to any table. Open the table
1373 editor with the '^' key, choose a table if needed, and press 'o' to
1374 open the color editor dialog.
1375 The color editor dialog displays the rules applied to the table, in the
1377 order they are evaluated. Each row is evaluated against each rule to
1378 see if the rule matches the row; if it does, the row gets the specified
1379 color, and no further rules are evaluated. The rules look like the
1380 following:
1381 state eq Locked black on_red
1383 cmd eq Sleep white
1384 user eq system user white
1385 cmd eq Connect white
1386 cmd eq Binlog Dump white
1387 time > 600 red
1388 time > 120 yellow
1389 time > 60 green
1390 time > 30 cyan
1391 This is the default rule set for the "processlist" table. In order of
1393 priority, these rules make locked queries black on a red background,
1394 "gray out" connections from replication and sleeping queries, and make
1395 queries turn from cyan to red as they run longer.
1396 (For some reason, the ANSI color code "white" is actually a light gray.
1398 Your terminal's display may vary; experiment to find colors you like).
1399 You can use keystrokes to move the rules up and down, which re-orders
1401 their priority. You can also delete rules and add new ones. If you
1402 add a new rule, innotop prompts you for the column, an operator for the
1403 comparison, a value against which to compare the column, and a color to
1404 assign if the rule matches. There is auto-completion and prompting at
1405 each step.
1406 The value in the third step needs to be correctly quoted. innotop does
1408 not try to quote the value because it doesn't know whether it should
1409 treat the value as a string or a number. If you want to compare the
1410 column against a string, as for example in the first rule above, you
1411 should enter 'Locked' surrounded by quotes. If you get an error
1412 message about a bareword, you probably should have quoted something.
1413 EXPRESSIONS
1415 Expressions are at the core of how innotop works, and are what enables
1416 you to extend innotop as you wish. Recall the table lifecycle
1417 explained in "TABLES". Expressions are used in the earliest step,
1418 where it extracts values from a data source to form rows.
1419 It does this by calling a subroutine for each column, passing it the
1421 source data set, a set of current values, and a set of previous values.
1422 These are all needed so the subroutine can calculate things like the
1423 difference between this tick and the previous tick.
1424 The subroutines that extract the data from the set are compiled from
1426 expressions. This gives significantly more power than just naming the
1427 values to fill the columns, because it allows the column's value to be
1428 calculated from whatever data is necessary, but avoids the need to
1429 write complicated and lengthy Perl code.
1430 innotop begins with a string of text that can look as simple as a
1432 value's name or as complicated as a full-fledged Perl expression. It
1433 looks at each 'bareword' token in the string and decides whether it's
1434 supposed to be a key into the $set hash. A bareword is an unquoted
1435 value that isn't already surrounded by code-ish things like dollar
1436 signs or curly brackets. If innotop decides that the bareword isn't a
1437 function or other valid Perl code, it converts it into a hash access.
1438 After the whole string is processed, innotop compiles a subroutine,
1439 like this:
1440 sub compute_column_value {
1442 my ( $set, $cur, $pre ) = @_;
1443 my $val = # EXPANDED STRING GOES HERE
1444 return $val;
1445 }
1446 Here's a concrete example, taken from the header table "q_header" in
1448 "Q: Query List" mode. This expression calculates the qps, or Queries
1449 Per Second, column's values, from the values returned by SHOW STATUS:
1450 Questions/Uptime_hires
1452 innotop decides both words are barewords, and transforms this
1454 expression into the following Perl code:
1455 $set->{Questions}/$set->{Uptime_hires}
1457 When surrounded by the rest of the subroutine's code, this is
1459 executable Perl that calculates a high-resolution queries-per-second
1460 value.
1461 The arguments to the subroutine are named $set, $cur, and $pre. In
1463 most cases, $set and $cur will be the same values. However, if
1464 "status_inc" is set, $cur will not be the same as $set, because $set
1465 will already contain values that are the incremental difference between
1466 $cur and $pre.
1467 Every column in innotop is computed by subroutines compiled in the same
1469 fashion. There is no difference between innotop's built-in columns and
1470 user-defined columns. This keeps things consistent and predictable.
1471 TRANSFORMATIONS
1473 Transformations change how a value is rendered. For example, they can
1474 take a number of seconds and display it in H:M:S format. The following
1475 transformations are defined:
1476 commify
1478 Adds commas to large numbers every three decimal places.
1479 dulint_to_int
1481 Accepts two unsigned integers and converts them into a single
1482 longlong. This is useful for certain operations with InnoDB, which
1483 uses two integers as transaction identifiers, for example.
1484 no_ctrl_char
1486 Removes quoted control characters from the value. This is affected
1487 by the "charset" configuration variable.
1488 This transformation only operates within quoted strings, for
1490 example, values to a SET clause in an UPDATE statement. It will
1491 not alter the UPDATE statement, but will collapse the quoted string
1492 to [BINARY] or [TEXT], depending on the charset.
1493 percent
1495 Converts a number to a percentage by multiplying it by two,
1496 formatting it with "num_digits" digits after the decimal point, and
1497 optionally adding a percent sign (see "show_percent").
1498 secs_to_time
1500 Formats a number of seconds as time in days+hours:minutes:seconds
1501 format.
1502 set_precision
1504 Formats numbers with "num_digits" number of digits after the
1505 decimal point.
1506 shorten
1508 Formats a number as a unit of 1024 (k/M/G/T) and with "num_digits"
1509 number of digits after the decimal point.
1510 TABLE EDITOR
1512 The innotop table editor lets you customize tables with keystrokes.
1513 You start the table editor with the '^' key. If there's more than one
1514 table on the screen, it will prompt you to choose one of them. Once
1515 you do, innotop will show you something like this:
1516 Editing table definition for Buffer Pool. Press ? for help, q to quit.
1518 name hdr label src
1520 cxn CXN Connection from which cxn
1521 buf_pool_size Size Buffer pool size IB_bp_buf_poo
1522 buf_free Free Bufs Buffers free in the b IB_bp_buf_fre
1523 pages_total Pages Pages total IB_bp_pages_t
1524 pages_modified Dirty Pages Pages modified (dirty IB_bp_pages_m
1525 buf_pool_hit_rate Hit Rate Buffer pool hit rate IB_bp_buf_poo
1526 total_mem_alloc Memory Total memory allocate IB_bp_total_m
1527 add_pool_alloc Add'l Pool Additonal pool alloca IB_bp_add_poo
1528 The first line shows which table you're editing, and reminds you again
1530 to press '?' for a list of key mappings. The rest is a tabular
1531 representation of the table's columns, because that's likely what
1532 you're trying to edit. However, you can edit more than just the
1533 table's columns; this screen can start the filter editor, color rule
1534 editor, and more.
1535 Each row in the display shows a single column in the table you're
1537 editing, along with a couple of its properties such as its header and
1538 source expression (see "EXPRESSIONS").
1539 The key mappings are Vim-style, as in many other places. Pressing 'j'
1541 and 'k' moves the highlight up or down. You can then (d)elete or
1542 (e)dit the highlighted column. You can also (a)dd a column to the
1543 table. This actually just activates one of the columns already defined
1544 for the table; it prompts you to choose from among the columns
1545 available but not currently displayed. Finally, you can re-order the
1546 columns with the '+' and '-' keys.
1547 You can do more than just edit the columns with the table editor, you
1549 can also edit other properties, such as the table's sort expression and
1550 group-by expression. Press '?' to see the full list, of course.
1551 If you want to really customize and create your own column, as opposed
1553 to just activating a built-in one that's not currently displayed, press
1554 the (n)ew key, and innotop will prompt you for the information it
1555 needs:
1556 · The column name: this needs to be a word without any funny
1558 characters, e.g. just letters, numbers and underscores.
1559 · The column header: this is the label that appears at the top of the
1561 column, in the table header. This can have spaces and funny
1562 characters, but be careful not to make it too wide and waste space
1563 on-screen.
1564 · The column's data source: this is an expression that determines
1566 what data from the source (see "TABLES") innotop will put into the
1567 column. This can just be the name of an item in the source, or it
1568 can be a more complex expression, as described in "EXPRESSIONS".
1569 Once you've entered the required data, your table has a new column.
1571 There is no difference between this column and the built-in ones; it
1572 can have all the same properties and behaviors. innotop will write the
1573 column's definition to the configuration file, so it will persist
1574 across sessions.
1575 Here's an example: suppose you want to track how many times your slaves
1577 have retried transactions. According to the MySQL manual, the
1578 Slave_retried_transactions status variable gives you that data: "The
1579 total number of times since startup that the replication slave SQL
1580 thread has retried transactions. This variable was added in version
1581 5.0.4." This is appropriate to add to the "slave_sql_status" table.
1582 To add the column, switch to the replication-monitoring mode with the
1584 'M' key, and press the '^' key to start the table editor. When
1585 prompted, choose slave_sql_status as the table, then press 'n' to
1586 create the column. Type 'retries' as the column name, 'Retries' as the
1587 column header, and 'Slave_retried_transactions' as the source. Now the
1588 column is created, and you see the table editor screen again. Press
1589 'q' to exit the table editor, and you'll see your column at the end of
1590 the table.
1591
1593 Variable sets are used in "S: Variables & Status" mode to define more
1594 easily what variables you want to monitor. Behind the scenes they are
1595 compiled to a list of expressions, and then into a column list so they
1596 can be treated just like columns in any other table, in terms of data
1597 extraction and transformations. However, you're protected from the
1598 tedious details by a syntax that ought to feel very natural to you: a
1599 SQL SELECT list.
1600 The data source for variable sets, and indeed the entire S mode, is the
1602 combination of SHOW STATUS, SHOW VARIABLES, and SHOW INNODB STATUS.
1603 Imagine that you had a huge table with one column per variable returned
1604 from those statements. That's the data source for variable sets. You
1605 can now query this data source just like you'd expect. For example:
1606 Questions, Uptime, Questions/Uptime as QPS
1608 Behind the scenes innotop will split that variable set into three
1610 expressions, compile them and turn them into a table definition, then
1611 extract as usual. This becomes a "variable set," or a "list of
1612 variables you want to monitor."
1613 innotop lets you name and save your variable sets, and writes them to
1615 the configuration file. You can choose which variable set you want to
1616 see with the 'c' key, or activate the next and previous sets with the
1617 '>' and '<' keys. There are many built-in variable sets as well, which
1618 should give you a good start for creating your own. Press 'e' to edit
1619 the current variable set, or just to see how it's defined. To create a
1620 new one, just press 'c' and type its name.
1621 You may want to use some of the functions listed in "TRANSFORMATIONS"
1623 to help format the results. In particular, "set_precision" is often
1624 useful to limit the number of digits you see. Extending the above
1625 example, here's how:
1626 Questions, Uptime, set_precision(Questions/Uptime) as QPS
1628 Actually, this still needs a little more work. If your "interval" is
1630 less than one second, you might be dividing by zero because Uptime is
1631 incremental in this mode by default. Instead, use Uptime_hires:
1632 Questions, Uptime, set_precision(Questions/Uptime_hires) as QPS
1634 This example is simple, but it shows how easy it is to choose which
1636 variables you want to monitor.
1637
1639 innotop has a simple but powerful plugin mechanism by which you can
1640 extend or modify its existing functionality, and add new functionality.
1641 innotop's plugin functionality is event-based: plugins register
1642 themselves to be called when events happen. They then have a chance to
1643 influence the event.
1644 An innotop plugin is a Perl module placed in innotop's "plugin_dir"
1646 directory. On UNIX systems, you can place a symbolic link to the
1647 module instead of putting the actual file there. innotop automatically
1648 discovers the file. If there is a corresponding entry in the "plugins"
1649 configuration file section, innotop loads and activates the plugin.
1650 The module must conform to innotop's plugin interface. Additionally,
1652 the source code of the module must be written in such a way that
1653 innotop can inspect the file and determine the package name and
1654 description.
1655 Package Source Convention
1657 innotop inspects the plugin module's source to determine the Perl
1658 package name. It looks for a line of the form "package Foo;" and if
1659 found, considers the plugin's package name to be Foo. Of course the
1660 package name can be a valid Perl package name, with double semicolons
1661 and so on.
1662 It also looks for a description in the source code, to make the plugin
1664 editor more human-friendly. The description is a comment line of the
1665 form "# description: Foo", where "Foo" is the text innotop will
1666 consider to be the plugin's description.
1667 Plugin Interface
1669 The innotop plugin interface is quite simple: innotop expects the
1670 plugin to be an object-oriented module it can call certain methods on.
1671 The methods are
1672 new(%variables)
1674 This is the plugin's constructor. It is passed a hash of innotop's
1675 variables, which it can manipulate (see "Plugin Variables"). It
1676 must return a reference to the newly created plugin object.
1677 At construction time, innotop has only loaded the general
1679 configuration and created the default built-in variables with their
1680 default contents (which is quite a lot). Therefore, the state of
1681 the program is exactly as in the innotop source code, plus the
1682 configuration variables from the "general" section in the config
1683 file.
1684 If your plugin manipulates the variables, it is changing global
1686 data, which is shared by innotop and all plugins. Plugins are
1687 loaded in the order they're listed in the config file. Your plugin
1688 may load before or after another plugin, so there is a potential
1689 for conflict or interaction between plugins if they modify data
1690 other plugins use or modify.
1691 register_for_events()
1693 This method must return a list of events in which the plugin is
1694 interested, if any. See "Plugin Events" for the defined events.
1695 If the plugin returns an event that's not defined, the event is
1696 ignored.
1697 event handlers
1699 The plugin must implement a method named the same as each event for
1700 which it has registered. In other words, if the plugin returns
1701 qw(foo bar) from register_for_events(), it must have foo() and
1702 bar() methods. These methods are callbacks for the events. See
1703 "Plugin Events" for more details about each event.
1704 Plugin Variables
1706 The plugin's constructor is passed a hash of innotop's variables, which
1707 it can manipulate. It is probably a good idea if the plugin object
1708 saves a copy of it for later use. The variables are defined in the
1709 innotop variable %pluggable_vars, and are as follows:
1710 action_for
1712 A hashref of key mappings. These are innotop's global hot-keys.
1713 agg_funcs
1715 A hashref of functions that can be used for grouping. See
1716 "GROUPING".
1717 config
1719 The global configuration hash.
1720 connections
1722 A hashref of connection specifications. These are just
1723 specifications of how to connect to a server.
1724 dbhs
1726 A hashref of innotop's database connections. These are actual DBI
1727 connection objects.
1728 filters
1730 A hashref of filters applied to table rows. See "FILTERS" for
1731 more.
1732 modes
1734 A hashref of modes. See "MODES" for more.
1735 server_groups
1737 A hashref of server groups. See "SERVER GROUPS".
1738 tbl_meta
1740 A hashref of innotop's table meta-data, with one entry per table
1741 (see "TABLES" for more information).
1742 trans_funcs
1744 A hashref of transformation functions. See "TRANSFORMATIONS".
1745 var_sets
1747 A hashref of variable sets. See "VARIABLE SETS".
1748 Plugin Events
1750 Each event is defined somewhere in the innotop source code. When
1751 innotop runs that code, it executes the callback function for each
1752 plugin that expressed its interest in the event. innotop passes some
1753 data for each event. The events are defined in the %event_listener_for
1754 variable, and are as follows:
1755 extract_values($set, $cur, $pre, $tbl)
1757 This event occurs inside the function that extracts values from a
1758 data source. The arguments are the set of values, the current
1759 values, the previous values, and the table name.
1760 set_to_tbl
1762 Events are defined at many places in this subroutine, which is
1763 responsible for turning an arrayref of hashrefs into an arrayref of
1764 lines that can be printed to the screen. The events all pass the
1765 same data: an arrayref of rows and the name of the table being
1766 created. The events are set_to_tbl_pre_filter,
1767 set_to_tbl_pre_sort,set_to_tbl_pre_group, set_to_tbl_pre_colorize,
1768 set_to_tbl_pre_transform, set_to_tbl_pre_pivot,
1769 set_to_tbl_pre_create, set_to_tbl_post_create.
1770 draw_screen($lines)
1772 This event occurs inside the subroutine that prints the lines to
1773 the screen. $lines is an arrayref of strings.
1774 Simple Plugin Example
1776 The easiest way to explain the plugin functionality is probably with a
1777 simple example. The following module adds a column to the beginning of
1778 every table and sets its value to 1.
1779 use strict;
1781 use warnings FATAL => 'all';
1782 package Innotop::Plugin::Example;
1784 # description: Adds an 'example' column to every table
1785 sub new {
1787 my ( $class, %vars ) = @_;
1788 # Store reference to innotop's variables in $self
1789 my $self = bless { %vars }, $class;
1790 # Design the example column
1792 my $col = {
1793 hdr => 'Example',
1794 just => '',
1795 dec => 0,
1796 num => 1,
1797 label => 'Example',
1798 src => 'example', # Get data from this column in the data source
1799 tbl => '',
1800 trans => [],
1801 };
1802 # Add the column to every table.
1804 my $tbl_meta = $vars{tbl_meta};
1805 foreach my $tbl ( values %$tbl_meta ) {
1806 # Add the column to the list of defined columns
1807 $tbl->{cols}->{example} = $col;
1808 # Add the column to the list of visible columns
1809 unshift @{$tbl->{visible}}, 'example';
1810 }
1811 # Be sure to return a reference to the object.
1813 return $self;
1814 }
1815 # I'd like to be called when a data set is being rendered into a table, please.
1817 sub register_for_events {
1818 my ( $self ) = @_;
1819 return qw(set_to_tbl_pre_filter);
1820 }
1821 # This method will be called when the event fires.
1823 sub set_to_tbl_pre_filter {
1824 my ( $self, $rows, $tbl ) = @_;
1825 # Set the example column's data source to the value 1.
1826 foreach my $row ( @$rows ) {
1827 $row->{example} = 1;
1828 }
1829 }
1830 1;
1832 Plugin Editor
1834 The plugin editor lets you view the plugins innotop discovered and
1835 activate or deactivate them. Start the editor by pressing $ to start
1836 the configuration editor from any mode. Press the 'p' key to start the
1837 plugin editor. You'll see a list of plugins innotop discovered. You
1838 can use the 'j' and 'k' keys to move the highlight to the desired one,
1839 then press the * key to toggle it active or inactive. Exit the editor
1840 and restart innotop for the changes to take effect.
1841
1843 innotop uses a limited set of SQL statements to retrieve data from
1844 MySQL for display. The statements are customized depending on the
1845 server version against which they are executed; for example, on MySQL 5
1846 and newer, INNODB_STATUS executes "SHOW ENGINE INNODB STATUS", while on
1847 earlier versions it executes "SHOW INNODB STATUS". The statements are
1848 as follows:
1849 Statement SQL executed
1851 =================== ===============================
1852 INNODB_STATUS SHOW [ENGINE] INNODB STATUS
1853 KILL_CONNECTION KILL
1854 KILL_QUERY KILL QUERY
1855 OPEN_TABLES SHOW OPEN TABLES
1856 PROCESSLIST SHOW FULL PROCESSLIST
1857 SHOW_MASTER_LOGS SHOW MASTER LOGS
1858 SHOW_MASTER_STATUS SHOW MASTER STATUS
1859 SHOW_SLAVE_STATUS SHOW SLAVE STATUS
1860 SHOW_STATUS SHOW [GLOBAL] STATUS
1861 SHOW_VARIABLES SHOW [GLOBAL] VARIABLES
1862
1864 Each time innotop extracts values to create a table (see "EXPRESSIONS"
1865 and "TABLES"), it does so from a particular data source. Largely
1866 because of the complex data extracted from SHOW INNODB STATUS, this is
1867 slightly messy. SHOW INNODB STATUS contains a mixture of single values
1868 and repeated values that form nested data sets.
1869 Whenever innotop fetches data from MySQL, it adds two extra bits to
1871 each set: cxn and Uptime_hires. cxn is the name of the connection from
1872 which the data came. Uptime_hires is a high-resolution version of the
1873 server's Uptime status variable, which is important if your "interval"
1874 setting is sub-second.
1875 Here are the kinds of data sources from which data is extracted:
1877 STATUS_VARIABLES
1879 This is the broadest category, into which the most kinds of data
1880 fall. It begins with the combination of SHOW STATUS and SHOW
1881 VARIABLES, but other sources may be included as needed, for
1882 example, SHOW MASTER STATUS and SHOW SLAVE STATUS, as well as many
1883 of the non-repeated values from SHOW INNODB STATUS.
1884 DEADLOCK_LOCKS
1886 This data is extracted from the transaction list in the LATEST
1887 DETECTED DEADLOCK section of SHOW INNODB STATUS. It is nested two
1888 levels deep: transactions, then locks.
1889 DEADLOCK_TRANSACTIONS
1891 This data is from the transaction list in the LATEST DETECTED
1892 DEADLOCK section of SHOW INNODB STATUS. It is nested one level
1893 deep.
1894 EXPLAIN
1896 This data is from the result set returned by EXPLAIN.
1897 INNODB_TRANSACTIONS
1899 This data is from the TRANSACTIONS section of SHOW INNODB STATUS.
1900 IO_THREADS
1902 This data is from the list of threads in the the FILE I/O section
1903 of SHOW INNODB STATUS.
1904 INNODB_LOCKS
1906 This data is from the TRANSACTIONS section of SHOW INNODB STATUS
1907 and is nested two levels deep.
1908 OPEN_TABLES
1910 This data is from SHOW OPEN TABLES.
1911 PROCESSLIST
1913 This data is from SHOW FULL PROCESSLIST.
1914 OS_WAIT_ARRAY
1916 This data is from the SEMAPHORES section of SHOW INNODB STATUS and
1917 is nested one level deep. It comes from the lines that look like
1918 this:
1919 --Thread 1568861104 has waited at btr0cur.c line 424 ....
1921
1923 · You must connect to MySQL as a user who has the SUPER privilege for
1924 many of the functions.
1925 · If you don't have the SUPER privilege, you can still run some
1927 functions, but you won't necessarily see all the same data.
1928 · You need the PROCESS privilege to see the list of currently running
1930 queries in Q mode.
1931 · You need special privileges to start and stop slave servers.
1933 · You need appropriate privileges to create and drop the deadlock
1935 tables if needed (see "SERVER CONNECTIONS").
1936
1938 You need Perl to run innotop, of course. You also need a few Perl
1939 modules: DBI, DBD::mysql, Term::ReadKey, and Time::HiRes. These
1940 should be included with most Perl distributions, but in case they are
1941 not, I recommend using versions distributed with your operating system
1942 or Perl distribution, not from CPAN. Term::ReadKey in particular has
1943 been known to cause problems if installed from CPAN.
1944 If you have Term::ANSIColor, innotop will use it to format headers more
1946 readably and compactly. (Under Microsoft Windows, you also need
1947 Win32::Console::ANSI for terminal formatting codes to be honored). If
1948 you install Term::ReadLine, preferably Term::ReadLine::Gnu, you'll get
1949 nice auto-completion support.
1950 I run innotop on Gentoo GNU/Linux, Debian and Ubuntu, and I've had
1952 feedback from people successfully running it on Red Hat, CentOS,
1953 Solaris, and Mac OSX. I don't see any reason why it won't work on
1954 other UNIX-ish operating systems, but I don't know for sure. It also
1955 runs on Windows under ActivePerl without problem.
1956 I use innotop on MySQL versions 3.23.58, 4.0.27, 4.1.0, 4.1.22, 5.0.26,
1958 5.1.15, and 5.2.3. If it doesn't run correctly for you, that is a bug
1959 and I hope you report it.
1960
1962 $HOMEDIR/.innotop is used to store configuration information. Files
1963 include the configuration file innotop.ini, the core_dump file which
1964 contains verbose error messages if "debug" is enabled, and the plugins/
1965 subdirectory.
1966
1968 tick
1969 A tick is a refresh event, when innotop re-fetches data from
1970 connections and displays it.
1971
1973 I'm grateful to the following people for various reasons, and hope I
1974 haven't forgotten to include anyone:
1975 Allen K. Smith, Aurimas Mikalauskas, Bartosz Fenski, Brian Miezejewski,
1977 Christian Hammers, Cyril Scetbon, Dane Miller, David Multer, Dr. Frank
1978 Ullrich, Giuseppe Maxia, Google.com Site Reliability Engineers, Jan
1979 Pieter Kunst, Jari Aalto, Jay Pipes, Jeremy Zawodny, Johan Idren,
1980 Kristian Kohntopp, Lenz Grimmer, Maciej Dobrzanski, Michiel Betel,
1981 MySQL AB, Paul McCullagh, Sebastien Estienne, Sourceforge.net, Steven
1982 Kreuzer, The Gentoo MySQL Team, Trevor Price, Yaar Schnitman, and
1983 probably more people I've neglected to include.
1984 (If I misspelled your name, it's probably because I'm afraid of putting
1986 international characters into this documentation; earlier versions of
1987 Perl might not be able to compile it then).
1988
1990 This program is copyright (c) 2006 Baron Schwartz. Feedback and
1991 improvements are welcome.
1992 THIS PROGRAM IS PROVIDED "AS IS" AND WITHOUT ANY EXPRESS OR IMPLIED
1994 WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
1995 MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
1996 This program is free software; you can redistribute it and/or modify it
1998 under the terms of the GNU General Public License as published by the
1999 Free Software Foundation, version 2; OR the Perl Artistic License. On
2000 UNIX and similar systems, you can issue `man perlgpl' or `man
2001 perlartistic' to read these licenses.
2002 You should have received a copy of the GNU General Public License along
2004 with this program; if not, write to the Free Software Foundation, Inc.,
2005 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
2006 Execute innotop and press '!' to see this information at any time.
2008
2010 Baron Schwartz.
2011
2013 You can report bugs, ask for improvements, and get other help and
2014 support at <http://sourceforge.net/projects/innotop>. There are
2015 mailing lists, forums, a bug tracker, etc. Please use these instead of
2016 contacting me directly, as it makes my job easier and benefits others
2017 if the discussions are permanent and public. Of course, if you need to
2018 contact me in private, please do.
2019perl v5.12.0 2007-11-09 INNOTOP(1)