One useful feature of the Percona mysql builds are the User Statistics. They let you track detailed information about clients, individual user accounts, threads indexes and tables.
In particular I find the TABLE_STATISTICS worth graphing. It can answer a lot of questions
In particular I find the TABLE_STATISTICS worth graphing. It can answer a lot of questions
- Which tables are used (and not used!)
- What's the rate of rows updated and read
- Which tables are read or written the most
When you graph these values over time, you can even see changes in behavior. For instance, you may be looking at a view of innodb_rows_read that looks like this:
Ok, so there's a big jump in activity, but how do you narrow that down quickly? Here's a graph of TABLE_STATISTICS.ROWS_READ with a separate series for each table.
Here you can clearly see one table stands out as being responsible for that huge increase.
Important Note
The values in TABLE statistics are cumulative since the last time you ran FLUSH TABLE_STATISTICS; Normally with values that keep incrementing such as the Questions counter in the mysql statistics, you take the current value, and store the delta -- however I've found the the maximum value for most of the counters is a signed 2^32 value -- only about 2 billion. Those values would fill up quickly on my systems leaving the stats distorted. The bug doesn't look like it's being worked on right now
The solution I'm using for now is to let the collector flush the stats every time it gathers them. That means the value it records is always the delta since the last collection. Not the best, but it's the only way I've found to make sure they don't overflow the values.
PlanetMySQL Voting: Vote UP / Vote DOWN