Comments on: For MySQL DBA fame and glory. Prize included.

By: Shlomi Noach

Shlomi Noach — Tue, 02 Jun 2009 07:50:51 +0000

@Michael,

you are right; I was merely stating the fact, regardless of the 5 parameters limitation. I was in fact relating to Toba #8.

By: Michael

Michael — Tue, 02 Jun 2009 04:29:35 +0000

@Shlomi Noach:
True that for replication to work correctly you need to assign server_id, however as TOP 5 configuration parameters, I’d recommend log-bin and leave server_id out. Replication will not start correctly without server_id, however the server [as a master] will be ripe/ready to serve replication slaves (assuming binary logs are not purged). As a result, you will eventually be forced to set server_id …

By: Shlomi Noach

Shlomi Noach — Tue, 02 Jun 2009 04:21:51 +0000

Just to point out (competition aside) that for replication purpose, log-bin is not sufficient: one must also define server-id (and though this is a dynamic variable, it really should be set in the config file)

By: Gavin Towey

Gavin Towey — Mon, 01 Jun 2009 23:31:40 +0000

Also note that I didn’t choose to adjust sort_buffer_size, read_buffer_size or read_rnd_buffer_size since defaults in more recent versions of mysql are sensible values. They are the next values I’d tune *after* the top 5 above.

By: Gavin Towey

Gavin Towey — Mon, 01 Jun 2009 23:29:49 +0000

My 5 (assuming non-innodb system as suggested by key_buffer being the most obvious addition):
key_buffer_size:
# Large enough to hold current mysiam indexes, but no more than 2G or 25% of total system ram.

table_cache
# somewhere around 512 to 2048. Adjust this value up until the opened_tables status stops incrementing most of the time.

thread_cache_size
# probably around 32 to 128. Adjust it up until threads_created counter stops incrementing.

query_cache_size
# probably around 32M to 128M. Check the cache hits and fill rate for size. Check ratio of insert rate to hit rate to decide if query cache is even usefull. If there is a low number of hits compared to inserts, then it would be best to disable query cache.

log-bin
# incremental backups, and point in time recovery are critical. Plus it’s better to have this on, so you don’t require a server restart when it’s needed for replication or backups later.

By: Michael

Michael — Mon, 01 Jun 2009 16:38:22 +0000

log-bin
- For point in time recovery & replication

table_cache <= 1024
- WP opens and closes tables faster than you can sneeze. It also [heavily] uses temp tables. This can be a huge bottleneck if set too high.

query_cache_size
- WP is heavily read oriented, having an ample Query Cache size alleviates table accesses

read_rnd_buffer_size
- WP uses poorly written queries — many GROUP BY and ORDER BY. Setting this to a higher than normal value can help speed up these queries.

If MyISAM:
key_buffer_size (if large indexes, multiple key caches)
- To help cache keys in memory, try to avoid disk seeks

If InnoDB:
innodb_buffer_pool_size
- To help cache data in main memory, try and avoid disk seeks

By: Tobias

Tobias — Mon, 01 Jun 2009 14:32:58 +0000

@Tobia
While Wordpress is mostly readonly and does not use any of InnoDB’s optimizations (clustered indexes).
And in the past there were a few problems in using Innodb: SELECT COUNT(*) FROM tab; and such things.

By: David Minor

David Minor — Mon, 01 Jun 2009 14:30:13 +0000

Also consider if you are on a 32 or 64 bit machine. If 32, your large caches (e.g. innodb_buffer_pool and key_buffer_size) will be limited to 2G.

Remember that some values are per thread (connection) e.g.: read_buffer_size and some can be allocated multiple times per thread, e.g.: join_buffer_size

Other values are allocated globalally, e.g. innodb_buffer_pool and query_cache_size.

Keep in mind the total amount of physical memory on the server when you are calculating global buffers and per connection buffers (Also note the setting of max_connections. Can your server handle 1000 connections, for example, allocating as much per-thread memory as you’ve configured?)

By: Toba

Toba — Mon, 01 Jun 2009 10:46:24 +0000

Why every assumes MyISAM for wordpress? We run wordpress fine with Innodb

So mine are,

# Set InnoDB as default engine so wordpress will create tables as innodb.
default-storage-engine = InnoDB

# More memory for Innodb, I usually set this about 75% of all RAM if running only innodb.
innodb_buffer_pool_size = 1024M

# Table cache is still usefull even with innodb tablespace because we want to cache .frm files.
table_cache = 2048

# Binary logging for replication and PITR
bin-log = server-bin

# For both mysqld and mysqldump. Using bigger multiline inserts reading the sql dump is lot faster.
max_allowed_packet = 16M

By: Tobias

Tobias — Sun, 31 May 2009 23:18:01 +0000

My Config would be:

# While Wordpress relies on MyISAM and blogs are about 99.999% read-only we get a big benefit of a very big cache
query_cache_type = On
query_cache_size = 128M # we should know the RAM size but 128MB will never be too much for the use of this server (read-only sites)

# MyISAM has no crash recovery like InnoDB, so we have to do it a similar way, or we’ll have trouble some night (Moore’s Law)
myisam-recover = BACKUP,FORCE

# explained later
log-slow-queries

The other configuration options i would not touch – they are pretty ok. The basic wordpress functions do not use many tables, so there’s no need in increasing tablecache or keybuffersize.
And database querys of wordpress are optimized, we only need the logging feature for slow querys to see that “something ist not working correctly”, we choose false parameters, the os is swapping or maybe our raid is doing some consistency checks.

Tobias