You need to figure out what's slowing down your application. It could be
expensive queries which in turn could be caused by missing indexes. It could
be that the machine is too slow or the configuration of MySQL is
sub-optimal.

In this case, the machine looks fine.

I can't comment on queries or indexes.

Your tuning, I can.

set-variable    = key_buffer=512M

This one is important; it caches data from the database in memory. How big
is your database? Is it bigger than 512 meg? If so, is there free memory on
the machine? If so, I'd recommend bumping it up as much as you can; it's
faster to get data from memory than it is from disk.


set-variable    = sort_buffer=16M

This is used to sort the results of queries; it's per-connection. I believe
it is allocated on an as-needed basis. Regardless, are you doing a lot of
ORDER BY/GROUP BY in your queries? This might be a little high.


set-variable    = table_cache=1024

How many tables do you have? This tells the database how many tables to keep
open. It probably won't make much of a difference lowering it.


set-variable    = join_buffer=8M

This one is used to join tables where no indexes exist. In otherwords, if
you're using indexes, it won't be used.


set-variable    = record_buffer=8M

This is used for reading in rows after a sort (from the sort_buffer). Again,
per client. Do you need it?


set-variable    = query_cache_size=6M

This one can be a waste of memory, or a huge bonus. Queries and their result
sets are stored here. If you need to run the same query a second time, the
database just pulls the results from the cache.

There are a few issues, tho.

If you have a query,

"SELECT * FROM table_1 WHERE condition_1 = 12"

then the result of the query will be stored. But if the next statement is,
"UPDATE TABLE table_1..." then the data in the cache relating to table_1
have to be unloaded, as the UPDATE statement could have invalidated all of
it.

But, if you have some stock queries that constantly read data from tables
that, in the business logic of your application, are read-only (ie you
rarely, if ever, update the data in them), then the query cache can be a big
bonus.

Another interesting note is the query_cache_type variable. You can set it to
2 in the my.cnf file; this means that in your select statements, you add a
hint to tell the database to cache or not cache the results of the query. So
if you know a query and it's results are very dynamic, then it's not much
use to use the query cache and you can tell the database to not put it in
the query cache. The SELECT statement would look like, 'SELECT SQL_CACHE *
FROM table_1 WHERE...'. Here's the page:
http://www.mysql.com/doc/en/Query_Cache.html



Next, moving to InnoDB. I found that, properly tuned, InnoDB is almost as
fast as MyISAM. You'll want to set the innodb_buffer_pool_size as large as
possible (it's the MyISAM key_buffer) to cache as much data.

You'll need to set up a tablespace; you can put them all over your disks.
Finally, play with innodb_flush_method. I set it to O_DSYNC and got a
substantial increase in performance. Search the MySQL list-archives for
discussions on the options, or check out http://www.innodb.com


Hope that helps,
David



----- Original Message -----
From: "Rainer Sip" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, October 21, 2003 9:48 AM
Subject: Mysql Performance Question


I'm running a community site (Xoops) on Mysql 4.0.14.

I found that the speed of my site is slow during peak hours, when there
are 450 concurrent uers hanging on the site. Mytop showed that the
queries per second maxed at 500. I believe this could be higher,
provided that I have it running on a dedicated machine. I also noticed
the load average is very high (12+ during peak hours)

In the mid run I'm planning to mirgrate to innodb for higher concurrency
(I'm currently using myisam). However, I'm seeking suggestions in fine
tuning the parameters.

The machine is a Dell PowerEdge 4400 with 2 Xeon 1G processors and 2GB
of memory. There are 4 disks running raid 0+1. Attached the my.cnf for
your easy review. Thanks a lot in advance.

Cheers,
Rainer


[client]
socket=/var/lib/mysql/mysql.sock

[client]
socket=/var/lib/mysql/mysql.sock

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
skip-locking
set-variable    = key_buffer=512M
set-variable    = max_allowed_packet=1M
set-variable    = table_cache=1024
set-variable    = sort_buffer=16M
set-variable    = join_buffer=8M
set-variable    = record_buffer=8M
set-variable    = thread_cache=512
set-variable    = max_connections=500
set-variable    = tmp_table_size=128M
set-variable    = thread_concurrency=4
set-variable    = myisam_sort_buffer_size=512M
set-variable    = query_cache_size=6M
#set-variable   = max_connect_errors=1000
#set-variable   = back_log=100
#log-bin
skip-innodb

[mysql.server]
user=mysql
basedir=/var/lib

[safe_mysqld]
err-log=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

[mysqldump]
quick
set-variable    = max_allowed_packet=16M

[mysql]
no-auto-rehash
# Remove the next comment character if you are not familiar with SQL
#safe-updates

[isamchk]
set-variable    = key_buffer=256M
set-variable    = sort_buffer=124M
set-variable    = read_buffer=2M
set-variable    = write_buffer=2M

[myisamchk]
set-variable    = key_buffer=256M
set-variable    = sort_buffer=256M
set-variable    = read_buffer=8M
set-variable    = write_buffer=4M

[mysqlhotcopy]
interactive-timeout

-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:    http://lists.mysql.com/[EMAIL PROTECTED]

Reply via email to