I've been having a big mysql performance problem for a while now after a migration from a dedicated server to a cloud VM.

The issue ultimately requires production load to test, so it has been difficult to control all the variables. However, I have not been able to find any recommendations that have had a significant positive effect on our performance.

Azure support recommended creating a RAID array, a handful of innodb config changes, and a change to process limits and disk scheduling algorithm. This was done on test but it was difficult to measure any difference in speed. At some point while trying to develop a fully fleshed-out process for deploying these changes to production, the test server started exhibiting similar behavior. As a temporary fix, a feature which depended on a slow query was removed. This brought the test server back to normal speed, but only got the production server about 1/2way there.

Since nothing is improving, I'm tempted to just assume that Azure is inherently slower, but that doesn't make sense with the discrete drop in performance the test server exhibited... as if it "caught" whatever was wrong with production. Unfortunately I can't remember all the details of the state of the server before that happened.

Another issue is that we don't have a test server that's the same size as production, so we can only make a 4-disk raid array, and it's hard to tell how a performance difference on the 4-disk array would compare to a 16-disk array. However since most of our DB should be in memory at any time, I don't really know that IO is the issue. So I don't necessarily see this being a very productive line of investigation.

The way we are using our server is sort of queue-like which I know is frowned upon, but it will be difficult to rebuild this system in any other way in the immediate future. I've got an idea that maybe the Microsoft MySQL optimization recommendations do not take this sort of usage into account .

Here's the relevant parts of the DB config:

key_buffer_size         = 64M
max_allowed_packet      = 16M
thread_stack            = 192K
thread_stack            = 512K
thread_cache_size       = 16
myisam_recover_options  = BACKUP
max_connections        = 200
table_open_cache        = 4096
table_definition_cache  = 4096

query_cache_limit       = 1M
query_cache_size        = 64M

slow_query_log = 1
slow_query_log_file  = /var/log/mysql/slow-log


long_query_time = 10

server-id               = 732807

log_bin                 = /var/log/mysql/bin-log
relay_log_space_limit = 16G
expire_logs_days        = 10
max_binlog_size         = 100M

binlog_format                    = MIXED


sort_buffer_size = 1M
read_buffer_size = 1M
read_rnd_buffer_size = 1M

tmp_table_size = 64M
max_heap_table_size = 16M
max_heap_table_size = 64M

back_log = 100
max_connect_errors              = 10000
interactive-timeout             = 3600
wait-timeout                    = 600
bind-address                    =

### Storage Engines
default_storage_engine         = InnoDB
#innodb                          = FORCE


myisam_sort_buffer_size         = 128M

## InnoDB

innodb_buffer_pool_size        = 5G

innodb_log_file_size           = 100M
innodb_file_per_table          = 1
## Replication

## Logging

max_allowed_packet      = 16M


no-auto-rehash  # faster start of mysql but no tab completition


key_buffer_size         = 16M

Any advice on config, or more tips for debugging would be appreciated.

  • Your entire post boils down to "my server is not as fast as I want, what should I do?", which you'll probably agree is way too broad. Identify the statement that gives you most grief, look at its execution plan and InnoDB stats while it's running, and go from there. – mustaccio Feb 5 at 18:41
  • How do I monitor the innoDB stats while it's running? other than just show engine innodb status from the console hoping to time it right? – scl Feb 5 at 20:13
  • 1
    Is it CPU bound? Or IO bound? What IO capacity are you using should answer your 4 vs 16 raid. What is SHOW ENGINE INNODB STATUS and SHOW GLOBAL STATUS. Queue implementations are discouraged because they are hard to get right, and lock excessively. Sometime you can't tune your way out of it. You may want to ask a separate question about your slow query. – danblack Feb 5 at 22:46
  • There are efficient ways and inefficient ways to implement a 'queue'. Please provide details on your implementation, including SHOW CREATE TABLE. – Rick James Feb 6 at 3:02
  • 1
    For configuration critique, please provide Ram size, SHOW VARIABLES; and SHOW GLOBAL STATUS; (after running for at least 24 hours). – Rick James Feb 6 at 18:49

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Browse other questions tagged or ask your own question.