views:

291

answers:

4

I currently have an application that is using 130 MySQL table all with MyISAM storage engine. Every table has multiple queries every second including select/insert/update/delete queries so the data and the indexes are constantly changing.

The problem I am facing is that the hard drive is unable to cope, with waiting times up to 6+ seconds for I/O access with so many read/writes being done by MySQL.

I was thinking of changing to just 1 table and making it memory based. I've never used a memory table for something with so many queries though, so I am wondering if anyone can give me any feedback on whether it would be the right thing to do?

A: 

Is there a specific reason you aren't using innodb? It may yield better performance due to caching and a different concurrency model. It likely will require more tuning, but may yield much better results.

should-you-move-from-myisam-to-innodb

Mainguy
I tried InnoDB and it is much much much slower than MyISAM. A query that takes about 0.2 seconds with MyISAM takes about 5 seconds with InnoDB.
Tim
+2  A: 

One possibility is that there may be other issues causing performance problems - 6 seconds seems excessive for CRUD operations, even on a complex database. Bear in mind that (back in the day) ArsDigita could handle 30 hits per second on a two-way Sun Ultra 2 (IIRC) with fairly modest disk configuration. A modern low-mid range server with a sensible disk layout and appropriate tuning should be able to cope with quite a substantial workload.

  • Are you missing an index? - check the query plans of the slow queries for table scans where they shouldn't be.

  • What is the disk layout on the server? - do you need to upgrade your hardware or fix some disk configuration issues (e.g. not enough disks, logs on the same volume as data).

  • As the other poster suggests, you might want to use InnoDB on the heavily written tables.

  • Check the setup for memory usage on the database server. You may want to configure more cache.

Edit: Database logs should live on quiet disks of their own. They use a sequential access pattern with many small sequential writes. Where they share disks with a random access work load like data files the random disk access creates a big system performance bottleneck on the logs. Note that this is write traffic that needs to be completed (i.e. written to physical disk), so caching does not help with this.

ConcernedOfTunbridgeWells
CPU usage is about 2%, memory is using about 450MB out of 6GB.The only bottleneck on server is the hard drive.There are 2 drives in the server running in RAID-1 (hardware RAID card) they are both 10K RPM SCSI drives.
Tim
At the very least, the DB logs should be on a physically separate disk (see above), so you should add another mirrored pair to the server for the logs. You might also check your query plans to see if the database is doing something silly or needs an index added.
ConcernedOfTunbridgeWells
DB logging is disabled. We are going to change from RAID 1 to 1+0 with 2 more drives added to the array. I'll also try changing the main query on the tables from "select id from table where status=1 order by rand() limit 1" to just "select id from table where status=1 limit 1". I'll post back the results of the changes later today.
Tim
See if putting an index on (Status, ID) helps (if such an index is not already present)
ConcernedOfTunbridgeWells
ID is primary key and status is index. I'm just waiting for the hard drives so I can try out RAID 10, probably not gonna be until tomorrow now.
Tim
Status is probably quite low cardinality which means that query optimiser may still not use that index. Take a look at the query plans and see if the index is actually being used.
ConcernedOfTunbridgeWells
id select_type table type possible_keys key key_len ref rows Extra1 SIMPLE table1 ref status status 1 const 350 Using temporary; Using filesort
Tim
With the "order by rand()" removed: id select_type table type possible_keys key key_len ref rows Extra1 SIMPLE table1 ref status status 1 const 177 Using where
Tim
A: 

I think that that your database structure is very wrong and needs to be optimised, has nothing to do with the storage

mazgalici
+1  A: 

I've now changed to a MEMORY table and everything is much better. In fact I now have extra spare resources on the server allowing for further expansion of operations.

Tim