(Assuming you are on Linux)
Take a look at the output of: iostate -xk 60
The output will update every 60 secs. Take a look at the value in the %util
column after a few updates, if it's around 90% you have become disk bound
and you'll need to figure out a way to decrease some load on the disk. You
may need to increase the size of innodb_buffer_pool if you DB is mostly
innodb tables. Add more RAM to the server if needed. You may also want to
add more disks to your disk array (assuming you have one). Move logs from
this disk array to another (binary logs, query logs, etc).
You can also look at your rkB/s (reads) and wkB/s (writes). If you are read
heavy, you may need to change the kind of RAID you are using for one that
performs better when reading. Same goes for write heavy, pick the best RAID
for your use.
On Thu, Jan 13, 2011 at 1:44 PM, Steve Staples <sstaples@stripped> wrote:
> I've been noticing a little lag in my application lately, it seems as
> if 1 table in 1 database is getting slower to read from. Mind you,
> that table is being accessed a LOT of times per second every hour of
> every day, and then the "application" searches on this same table too.
> In my sandbox, it is fast to search (as there is no other reads/queries
> on that table), so i don't think it is disk i/o (but you never know
> right?). I've also double checked all the indexing, to insure indexes
> are used.
> What I was wondering is, are the reads/queries simultaneous, or are they
> sequential? would symlinking the file to another db make any difference
> (or is that even possible)?
> any insight would be appreciated, or even any ideas on what I may do to
> increase the performance, or even how to measure where the issue could
> be would help as well.
> MySQL General Mailing List
> For list archives: http://lists.mysql.com/mysql
> To unsubscribe: http://lists.mysql.com/mysql?unsub=1