Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

(Debian 7 32-bits KVM with 512mb RAM - SSD storage - 1 cpu)

The server is not mysql dedicated.

It runs a small forum on it. (Mysql -> read-mostly)

Does anyone have any advice as to how I can optimise my MySQL installation?

The server have no lags on peak times.


My current config in my my.cnf file is:


# Logs

# Buffers



#Temp tables





When I run MySQLTuner, this is what I get:

>>  MySQLTuner 1.3.0 - Major Hayden <>
>>  Bug reports, feature requests, and downloads at
>>  Run with '--help' for additional options and output filtering
[OK] Logged in using credentials from debian maintenance account.
[OK] Currently running supported MySQL version 5.5.36-34.2-648.wheezy
[OK] Operating on 32-bit architecture with less than 2GB RAM

-------- Storage Engine Statistics -------------------------------------------
[--] Data in MyISAM tables: 5M (Tables: 64)
[--] Data in InnoDB tables: 82M (Tables: 195)
[--] Data in PERFORMANCE_SCHEMA tables: 0B (Tables: 17)
[--] Data in MEMORY tables: 252K (Tables: 3)
[!!] Total fragmented tables: 26

-------- Security Recommendations  -------------------------------------------
[OK] All database users have passwords assigned

-------- Performance Metrics -------------------------------------------------
[--] Up for: 8d 4h 46m 25s (2M q [3.459 qps], 181K conn, TX: 7B, RX: 521M)
[--] Reads / Writes: 54% / 46%
[--] Total buffers: 304.0M global + 2.6M per thread (50 max threads)
[!!] Maximum possible memory usage: 432.1M (86% of installed RAM)
[OK] Slow queries: 0% (0/2M)
[OK] Highest usage of available connections: 62% (31/50)
[OK] Key buffer size / total MyISAM indexes: 16.0M/5.1M
[OK] Key buffer hit rate: 99.8% (1M cached / 2K reads)
[OK] Query cache efficiency: 74.4% (1M cached / 1M selects)
[!!] Query cache prunes per day: 3959
[OK] Sorts requiring temporary tables: 0% (21 temp sorts / 81K sorts)
[!!] Joins performed without indexes: 30762
[!!] Temporary tables created on disk: 46% (74K on disk / 160K total)
[OK] Thread cache hit rate: 86% (25K created / 181K connections)
[!!] Table cache hit rate: 10% (347 open / 3K opened)
[OK] Open file limit used: 8% (178/2K)
[OK] Table locks acquired immediately: 99% (1M immediate / 1M locks)
[OK] InnoDB buffer pool / data size: 128.0M/82.8M
[OK] InnoDB log waits: 0
-------- Recommendations -----------------------------------------------------
General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
    Reduce your overall MySQL memory footprint for system stability
    Enable the slow query log to troubleshoot bad queries
    Adjust your join queries to always utilize indexes
    When making adjustments, make tmp_table_size/max_heap_table_size equal
    Reduce your SELECT DISTINCT queries without LIMIT clauses
    Increase table_cache gradually to avoid file descriptor limits
    Read this before increasing table_cache over 64:
Variables to adjust:
    query_cache_size (> 16M)
    join_buffer_size (> 1.0M, or always use indexes with joins)
    tmp_table_size (> 128M)
    max_heap_table_size (> 128M)
    table_cache (> 1024)

When I run TUNING PRIMER, this is what I get:

             - By: Matthew Montgomery -

MySQL Version 5.5.36-34.2-648.wheezy i686

Uptime = 8 days 4 hrs 47 min 29 sec
Avg. qps = 3
Total Questions = 2450393
Threads Connected = 1

Server has been running for over 48hrs.
It should be safe to follow these recommendations

To find out more information on how each of these
runtime variables effects performance visit:
for info about MySQL's Enterprise Monitoring and Advisory Service

The slow query log is NOT enabled.
Current long_query_time = 10.000000 sec.
You have 0 out of 2450414 that take longer than 10.000000 sec. to complete
Your long_query_time seems to be fine

The binary update log is NOT enabled.
You will not be able to do point in time recovery

Current thread_cache_size = 1
Current threads_cached = 0
Current threads_per_sec = 0
Historic threads_per_sec = 0
Your thread_cache_size is fine

Current max_connections = 50
Current threads_connected = 1
Historic max_used_connections = 31
The number of used connections is 62% of the configured maximum.
Your max_connections variable seems to be fine.

Current InnoDB index space = 25 M
Current InnoDB data space = 82 M
Current InnoDB buffer pool free = 13 %
Current innodb_buffer_pool_size = 128 M
Depending on how much space your innodb indexes take up it may be safe
to increase this value to up to 2 / 3 of total system memory

Max Memory Ever Allocated : 255 M
Configured Max Per-thread Buffers : 128 M
Configured Max Global Buffers : 176 M
Configured Max Memory Limit : 304 M
Physical Memory : 502 M
Max memory limit seem to be within acceptable norms

Current MyISAM index space = 5 M
Current key_buffer_size = 16 M
Key cache miss rate is 1 : 513
Key buffer free ratio = 67 %
Your key_buffer_size seems to be fine

Query cache is enabled
Current query_cache_size = 16 M
Current query_cache_used = 9 M
Current query_cache_limit = 1 M
Current Query cache Memory fill ratio = 60.50 %
Current query_cache_min_res_unit = 4 K
MySQL won't cache query results that are larger than query_cache_limit in size

Current sort_buffer_size = 1 M
Current read_rnd_buffer_size = 256 K
Sort buffer seems to be fine

Current join_buffer_size = 1.00 M
You have had 30765 queries where a join could not use an index properly
You should enable "log-queries-not-using-indexes"
Then look for non indexed joins in the slow query log.
If you are unable to optimize your queries you may want to increase your
join_buffer_size to accommodate larger joins in one pass.

Note! This script will still suggest raising the join_buffer_size when
ANY joins not using indexes are found.

Current open_files_limit = 2109 files
The open_files_limit should typically be set to at least 2x-3x
that of table_cache if you have heavy MyISAM usage.
Your open_files_limit value seems to be fine

Current table_open_cache = 1024 tables
Current table_definition_cache = 400 tables
You have a total of 303 tables
You have 348 open tables.
The table_cache value seems to be fine

Current max_heap_table_size = 128 M
Current tmp_table_size = 128 M
Of 86516 temp tables, 46% were created on disk
Perhaps you should increase your tmp_table_size and/or max_heap_table_size
to reduce the number of disk-based temporary tables
Note! BLOB and TEXT columns are not allow in memory tables.
If you are using these columns raising these values might not impact your
ratio of on disk temp tables.

Current read_buffer_size = 128 K
Current table scan ratio = 489 : 1
read_buffer_size seems to be fine

Current Lock Wait ratio = 1 : 178950
Your table locking seems to be fine
share|improve this question

closed as off-topic by MadHatter, Nathan C, Andrew, Nixphoe, Mark Wagner May 14 '14 at 17:22

  • This question does not appear to be about server, networking, or related infrastructure administration within the scope defined in the help center.
If this question can be reworded to fit the rules in the help center, please edit the question.

See "Search and research Server Fault should be your last stop in your quest for an answer, and you should tell us what you found/tried in your research and why it didn’t meet your needs." – Mark Wagner May 14 '14 at 17:21

a couple of considerations:

  • you noticed you have no problems during peak for your database. Why fix something that isnt broke
  • performance tuning starts with the schema/database you have. datatypes, constraints, indexes all have an impact on your performance before you even start tuning.
  • whats your read/write %?
  • some of the performance checks u ran could display skewed data.. for instance tmp tables on disk can be due to the fact your schema has blob datatypes etc.
  • hardware is another thing. You say your using an ssd for storage. This blows any config tuning right out of the water for a database server of your size/load. Databases love ram :) especially engines like innodb.
  • match the storage engine with what kind of data you are storing in the database.
  • tune your buffers according to the memory of the system. for instance: you have a max of 50 connections and every connection gets 2.6m so thats already +100m on your server and that's already 25% of the total ram.
  • turn on off unused engines and functionality.
  • query cache can be really good or really bad. if u have a lot of unique queries u might as well turn it off. the amount of prunes can also indicate the cache is to small. Don't make it to big cos that will cause overhead just as easy.
  • use the slowquery log to see which queries could trouble your server and analyze those queries.
  • read up on people who actually know stuff ;) for instance here
  • if u only have one place to "test" be very careful!

what you ask is really difficult for anyone else to just answer. The scripts u ran are a good start. Use a couple of different scripts to test if the data you get back is what u expect and in line with each other.

My out of the box suggestion for now is to make sure you don't cause instability to the rest of your server because the server currently can use up most of the ram in the machine. of course 512m isn't a whole lot to work with but still.. so start with lowering global buffers without losing performance.

A from the mysqltuner script is tmp tables on disk. these are usually performance killers in larger environments.

Seeing you are using an SSD I think that the difference between a minimal config and a super tuned cnf wont make a noticeable difference. this of course if there aren't any poorly designed schemas/databases.

stop performance tuning when u think performance is good. its a task that is never really done. It is a hardcore subject and the possibilities are endless. you can waste hours and hours on tuning a small parts of your database.. whilst a human will never notice the difference in an environment your size.

I'm by no means a professional so i can be wrong. But I've been there and just wanted to share my experiences. I hope they help

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.