Vlad Fedorkov

Performance consulting for MySQL and Sphinx

What is stuck in MySQL server?

There are few easy ticks to see what is stuck inside MySQL instance. All these techniques will not give you whole picture, but might help to find queries that block performance. Let’s start from what exactly doing your MySQL server right now.

Which queries are running now?

This will give you an idea what’s running right now so you can find long running queries which slowing down MySQL and/or causing replication lag:

mysql -e "SHOW PROCESSLIST" | grep -v -i "sleep"

It is more convenient than just run “SHOW PROCESSLIST” as it’s hiding all connected threads in “Sleep” state so you’ll get a clean output. Also you can get same output but updating each second:

watch -n1 'mysql -e "SHOW FULL PROCESSLIST" | grep -v -i "Sleep"'

What to look for? This is complex output but you can start with Time and State columns. When you see a query running for more than one second it’s time for query review. If you sure it’s ok for query to be slow (like for queries in complex reports) you can move it away from critical server to special “reporting” replica.

When you see states like “Copying to tmp table” or any kinds of “Waiting …” like “Waiting for query cache lock” even if it’s fast then your server performance is less than stellar and it’s time to dig in.

How to collect bad qeuries

How to easily collect bad queries? Non-intrusive way is to listen MySQL network communications and dump all the data using tcpdump. This is extremely useful when you need to get an idea about most time consuming queries without touching MySQL configuration and query logging at all. This will also require Percona toolkit to be installed, but it’s worth it. Here is quick example. Let tcpdump run for some time and then run pt-query-digest to aggregate tcpdump output into readable report.

tcpdump -s 65535 -X -nn -q -tttt -i any port 3306 > mysql.tcp.txt
pt-query-digest --type tcpdump ./mysql.tcp.txt > digest.log

This will produce report with most resource consuming queries on the top. Optimizing them one by one will improve speed or your MySQL instances, application response time and so give you a chance to handle more traffic with less hardware.

Which engines are in use?

Where also to look? Performance optimization techniques quite complex but depends on the engine that you use to store data. InnoDB, MyISAM, TokuDB – they all require different approach in query tunning and troubleshooting. So next step is to see how your data is distributed across the engines. In that case the following query will help:

SELECT
    engine,
    count(*) TABLES,
    concat(round(sum(table_rows)/1000000,2),'M') rows,
    concat(round(sum(data_length+index_length)/(1024*1024*1024),2),'G') Size
FROM
    information_schema.TABLES
WHERE
    table_schema NOT IN
      ('mysql', 'information_schema', 'performance_schema')
GROUP BY engine
ORDER BY Size DESC;
Find all tables across all databases uses specific engine

Now you would probably like to see all tables that uses say MyISAM engine to store data. Here you go – example for MyISAM with big tables first.

SELECT
    concat(table_schema,'.',table_name),
    engine,
    concat(round(table_rows/1000000,2),'M') Rows,
    concat(round((data_length+index_length)/(1024*1024*1024),2),'G') Size
FROM
    information_schema.TABLES
WHERE
    engine = 'MyISAM' AND
    table_schema NOT IN
        ('mysql', 'information_schema', 'performance_schema')
ORDER BY
    Size DESC;

Keeping your queries in a good shape could save you money on hardware and make your application fast but it’s also cause servers to do less work which means less electricity consumed and less CO2 and heat released to the atmosphere. So it is good thing to do whatever you believe on global warming or not :)

Full table scans and MySQL performance

High season is coming, how do you make sure that MySQL will handle the increased load? Stress tests could help with that, but it’s not a good idea to run them in a production environment. In this case Select_scan, Select_full_join and other MySQL counters could quickly give you an idea of how many queries are not performing well and could cause a performance degradation as the load goes up.

Select_scan from SHOW GLOBAL STATUS indicates how many full table scans were done since last MySQL restart. Scanning the entire table is a resource intensive operation. It also forces MySQL to store unnecessary data in the buffer pool, wasting memory and IO resources. Continue reading

Difference between myisam_sort_buffer_size and sort_buffer_size

MySQL has two confusingly identical by the first look variables myisam_sort_buffer_size and sort_buffer_size. Thing is that those two confusingly similar variables has absolutely different meanings.

sort_buffer_size is a per-connection variable and do not belongs to any specific storage engine. It doesn’t matter do you use MyISAM or InnoDB – MySQL will allocate sort_buffer_size for every sort (required most of the times for ORDER BY and GROUP BY queries) so increasing it’s value might help speeding up those queries however I would not recommend to change it from the default value unless you are absolutely sure about all the drawbacks. Value for out-of-the-box MySQL-5.1.41 installation on Ubuntu is 2Mb and it’s recommended to keep it that way.

On the other side myisam_sort_buffer_size used by MyISAM to perform index sorting on relatively rare table-wide modifications like ALTER/REPAIR TABLE. Stock value is 8Mb so if you are using MyISAM tables intensively (please refer to my other post to see how to know your tables type) I would recommend to set it to some higher value close or even more than key_buffer_size but still small enough to keep it in memory and prevent MySQL from swapping.

Why is stock MySQL slow?

“I’ve installed MySQL and it doesn’t work fast enough for me”. MySQL server is heart of database driven application (if it uses MySQL as database of course!) and any slowness related to running queries is affecting all application layers.

MySQL server tuning and query slowness hunting are always step by step process and without knowing all the data (SHOW GLOBAL VARIABLES, SHOW GLOBAL STATUS, SHOW TABLE STATUS LIKE ‘tablename’, EXPLAIN details for slow query is just some of the required information) it would be generally a blind guess. But there are still few things which is related to newly installed MySQL server.

If you are using stock MySQL you might need to check memory pool size which MySQL used to load index data to avoid slow IO requests and increase queries speed. Connect to MySQL and fire two queries: Continue reading