Tracking SQL statistics with ExtSQL

Configuration Options

More than 100 vars (data items) are available. Configure the ExtSQL server by describing which vars you are interested in tracking and how you want to collect data. For a more complete example, consider this string, which must be one line in the configuration file:

As with SHOW STATUS (in this case with historical data), the server will track information on four different classes: user, db, host, and cumulative server stats.

For each class, max- precedes the maximum number of instances of that class. time- precedes the number of historical time units to store, and units- designates the period of interest (m, minutes; h, hours; d, days). After the limits for each class, a comma-separated list of vars is included. The line starting with db is a directive to track a maximum of 50 dbs and record historical data for each of the last 10 hours. The vars addressed in the preceding command are inserts, selects, updates, and query cache hits.

SHOW STATISTICS Syntax

The goal for command syntax was to stay as close to standard SQL as possible. The syntax described here should look familiar, especially if you replace SHOW STATISTICS with SELECT. Listing 1 shows some ExtSQL usage examples.

Significantly different are LIKE, to match specific instances, and the new keyword HISTORY, to produce historical output. LIMIT operates differently if HISTORY is specified. Without HISTORY, it limits the number of results displayed. With HISTORY, it functions as a time limit.

SHOW STATISTICS * FROM user WHERE user LIKE '%joe%' AND Com_select > 500

LIKE is a separate clause in the syntax that matched just Class instances. For now, the syntax is limited in the WHERE clause, and ORDER BY is available if INFORMATION SCHEMA is supported in your base version of the ExtSQL server.

Many of you are aware that INFORMATION SCHEMA is already part of the SQL standard, and its purpose is to make SQL databases more "self describing." The ExtSQL project already has an example working implementation for MySQL 5.0.x (see Listing 2).

Server Performance

Performance was a primary design constraint on ExtSQL. With more and more memory available on servers, it made sense to store data in RAM while giving the database administrator complete control over how much memory would be allocated. This resulted in an average performance effect of about 5% – an acceptable number on most servers.

For a better understanding of performance statistics, consider how ExtSQL records and reports time. With the class definition user, max-50, time-10, units-h, ExtSQL will create a buffer that holds 11 time periods. The 0 buffer always holds cumulative numbers since server start and is the number displayed in the command SHOW STATISTICS * FROM user.

Historical activity is captured for 10-hour periods in a circular manner and only when activity occurs (e.g., start the server and 20 hours later enter):

SHOW STATISTICS * FROM user HISTORY

Assume user activity was recorded in each of the first 10 hours of server operation, and then only in the last five hours (i.e., a five-hour gap with no activity). Activity that occurred between server operation hours 5 and 10 is reported by the hour, then the last five hours. Each row is timestamped to the hour. With the command SHOW STATISTICS * FROM user, you would see just one line of cumulative totals for all 20 hours.

Buy Linux Magazine

Related content

Sure, you've heard about systemd, which is rapidly replacing the old System V init system as the go-to service management daemon for the Linux world. But what can you do with systemd really? We'll show you some tricks for improving security, managing processes, and analyzing boot times with systemd.

Even hardened nerds are often over-challenged by the less than intuitive field of statistics. Besides the theory, you need to know how to use the software that converts all the theory into a practical application.