[lug] mysqldump versus snapshot versus..

steve at badcheese.com steve at badcheese.com
Thu Aug 2 16:11:12 MDT 2007


> based upon your experience, care to share any basic optimization
> techniques? my.cnf settings, etc? :-)

We set our "key_buffer" setting to 1/2 of available mem, which seems to do 
really well for large tables or large indexes.  No matter what kind of DB 
you use, you should 'know' your data and how it's used/queries/updated. 
If it's a small website, then you can just throw it all in a pot and stir 
it up, but if it's for other things, then you need to kind of tune 
accordingly.  Even Oracle can't read your mind with your usage and is able 
to be tuned in lots of different ways.

We had a situation once where we replaced the entire DB every 4 hours.  We 
had a small lag time after replacing the DB because none of the indexes 
had been cached, so we found a way to pre-cache the indexes (prime the DB 
as it were) before making the system live.  Mostly just for performance 
reasons.  We knew that the usage was unusual, but figured out a way to 
make it work.

Our basic my.cnf looks like:

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
old_passwords=1
log-bin=mysql-bin
server-id=1
key_buffer = 1999M

A really tricked-out one looks like:

[mysqld]
[...]
skip-locking
key_buffer = 1999M
max_allowed_packet = 1M
table_cache = 512
sort_buffer_size = 2M
read_buffer_size = 2M
myisam_sort_buffer_size = 64M
thread_cache = 8
query_cache_size = 32M
# Try number of CPU's*2 for thread_concurrency
# dual-quad-core = 8 CPUs
thread_concurrency = 16
ft_min_word_len = 3
server-id       = 3
log-bin=mysql-bin

- Steve

-- 
EMAIL: (h) steve at badcheese.com  WEB: http://badcheese.com/~steve




More information about the LUG mailing list