Recipe 9.12. Monitoring the MySQL Server

Problem

You want to find out how the server was configured or monitor its state.

Solution

SHOW VARIABLES and SHOW STATUS are useful for this.

Discussion

The SHOW VARIABLES and SHOW STATUS statements provide server configuration and performance information:

mysql> SHOW VARIABLES; +---------------------------------+-------------------+ | Variable_name                   | Value             | +---------------------------------+-------------------+ | back_log                        | 50                | | basedir                         | /usr/local/mysql/ | | bdb_cache_size                  | 8388600           | | bdb_log_buffer_size             | 0                 | | bdb_home                        |                   | ... mysql> SHOW /*!50002 GLOBAL */ STATUS; +--------------------------+----------+ | Variable_name            | Value    | +--------------------------+----------+ | Aborted_clients          | 319      | | Aborted_connects         | 22       | | Bytes_received           | 32085033 | | Bytes_sent               | 26379272 | | Connections              | 65684    | ... 

Both statements allow a LIKE ' pattern ' clause that takes an SQL pattern. In that case, only rows for variable names that match the pattern are returned.

The /*!50002 GLOBAL */ comment is present in the SHOW STATUS statement due to a change made in MySQL 5.0.2; before MySQL 5.0.2, status variables were global (server-wide values). In 5.0.2, status variables have global and session (per-connection) values, and SHOW STATUS has been extended to take GLOBAL or SESSION modifiers, with the default being, if neither is given, to display the session values. The comment causes servers from MySQL 5.0.2 and up to display the global values. Servers before 5.0.2 ignore the comment, but display global values because only global values exist in those versions. This idiom is used throughout this chapter.

System and status variable information can be useful for writing administrative applications. For example, the MyISAM key cache hit rate is a measure of how often key requests are satisfied from the cache without reading keys from disk. The following formula calculates the hit rate, where Key_reads and Key_read_requests indicate the number of disk reads and number of requests, respectively:

1 - (Key_reads / Key_read_requests) 

Values close to 1 indicate a high hit rate, which means that the key cache is very efficient. Values close to 0 indicate a low hit rate (possibly a sign that you should increase the value of the key_buffer_size system variable to use a larger cache). It's easy to calculate the hit rate in a program, as the following Ruby code illustrates:

# Execute SHOW STATUS to get relevant server status variables, use # names and values to construct hash of values keyed by names. stat_hash = {} stmt = "SHOW /*!50002 GLOBAL */ STATUS LIKE 'Key_read%'" dbh.select_all(stmt).each do |name, value|   stat_hash[name] = value end key_reads = stat_hash["Key_reads"].to_f key_reqs = stat_hash["Key_read_requests"].to_f hit_rate = key_reqs == 0 ? 0 : 1.0 - (key_reads / key_reqs) puts "        Key_reads: #{key_reads}" puts "Key_read_requests: #{key_reqs}" puts "         Hit rate: #{hit_rate}" 

As another example, you might write a long-running program that probes the server periodically to monitor its activity. A simple application of this type might ask the server to report the number of connections it's received and its uptime, to determine a running display of average connection activity. The statements to obtain this information are:

SHOW /*!50002 GLOBAL */ STATUS LIKE 'Connections'; SHOW /*!50002 GLOBAL */ STATUS LIKE 'Uptime'; 

If you want to avoid having to reconnect each time you issue the statements, you can ask the server for its client timeout period and probe it at intervals shorter than that value. You can get the timeout value (in seconds) with this statement:

SHOW VARIABLES LIKE 'wait_timeout'; 

The default value is 28800 (8 hours), but it might be configured to a different value on your system.

For system variables, an alternative way to access their values is by referring to them as @@ var_name. For example:

mysql> SELECT @@wait_timeout; +----------------+ | @@wait_timeout | +----------------+ | 28800          | +----------------+ 

This provides the convenience that you can select multiple values in a single row, and you can use the values directly within expressions.

The "MySQL Uncertainty Principle"

Heisenberg's uncertainty principle for measurement of quantum phenomena has a MySQL analog. If you monitor MySQL's status to see how it changes over time, you might notice the curious effect that, for some of the indicators, each time you take a measurement, you change the value you're measuring! For example, you can determine the number of statements the server has received by using the following statement:

SHOW /*!50002 GLOBAL */ STATUS LIKE 'Questions' 

However, that statement is itself a statement, so each time you issue it, you cause the Questions value to change. In effect, your performance assessment instrument contaminates its own measurements, something you might want to take into account.