Hi,

 

This is a bit of a long mail, so apologies in advance, I've tried to
five as much information as possible that I think might be useful
regarding my problem.

 

I have 3 tables where I keep cache records, the structures are something
like

 

      TableA      TableB      TableC

      Id          Id          Id

      ...         ...         ...

 

The Id is the primary key on all tables and link on this field.

 

      TableA is a 1 to many on TableB which is a 1 to many on TableC

 

To give you an idea of size, TableA has 8,686,769 rows, TableB has
5,6322,236 rows and TableC has 1,089,635,551 rows.

 

Whether date is to be expired/deleted is based on some rule about a date
in TableA.

 

To decide this I run a select query to get all Id's from tableA that
have expired.

This query takes a minute or 2 to run.

 

I then create a loop for all Id's doing

 

      delete from TableC where id=

      delete from TableB where id=

      delete from TableA where id=

 

I am grouping 10,000 loops into a transaction.

 

My expiry runs on a daily basis and deletes approximately this number of
rows from each table.

 

      TableA    500,000

      TableB  4,836,560

      TableC 71,534,549

 

I'm starting to run into problems where my expiry process is now taking
longer than 24 hours to complete.

Looking at system stats, the CPU is only at 33%, memory usage is normal
so it looks to me like the i/o is the bottle neck.

 

I'm wondering how I can improve the performance.

 

Firstly, the system I have is

 

      Redhat Enterprise ES rel 3 32-bit

      2 x Dual Core CPU

      16Gb Ram

      1 x 160Gb 10k SCSI drive boot drive

      5 x 160gb 10k SCSI drives RAID Level 1 all combined as 1 partition

 

I have 2 of these in a master/slave config, writes are to the master and
reads to the slave.

MySQL version is 4.1.12 and all tables are InnoDB.  File Systems are all
ext3.

 

 

I have some basic questions

 

1.      Would upgrading to a later MySQL version give any performance
improvements?
2.      If I could split the tables up into smaller tables would this
help ?  My dilemma here is that I can split the data, the data would be
in different tables but on the same hardware, the same number of deletes
would still have to happen so would it actually make any difference ?
3.      Would an alternative file system help, i.e. raw disk ?

 

I think I seem to be limited because of running on a linux 32-bit OS, I
am unable to take advantage of the 16Gb memory the hardware, if I try
and allocate more than 1.6Gb in my buffer pool, MySQL will not start, I
seem to recall this is due to a glibc/malloc issue.  If I were to move
to a 64-bit I believe this would go away.

 

I'd be grateful for any advice or suggestions with this.

 

Cheers,

 

Marvin

 

 

Reply via email to