Author Topic: (SOLVED)Mysql database getting very large -- Zarafa related  (Read 6056 times)

half_life

  • Bug Hunter
  • Zen Hero
  • *****
  • Posts: 867
  • Karma: +59/-0
    • View Profile
(SOLVED)Mysql database getting very large -- Zarafa related
« on: December 01, 2012, 11:05:39 pm »
I have come up with some interesting findings today.  I run Zentyal 2.2 with pretty much all modules installed.  This server was upgraded from 2.0 back in April.  What is getting my attention is that mysqld uses quite a bit of cpu even when idle (140%-160% on a quad core VM).  I am also getting short on space in my root directory.  The system was originally the stock 8gb root partition later expanded to 100gb via lvm.  We have approximately 125 users that use Zarafa.  The system has been in production for 2 years now.

The mysql directory has grown to 57gb and the ibdata1 file accounts for most of that.  Mysql is in the default setup and this is where the problem is.  By default, mysql stores all databases in ibdata1.  When a record is deleted the storage space is not released so the file continues to grow.  Running table optimize will not help since the "optimized" data will be written to the end of the file. In my case the actual data is only about 16gb not the 57gb taken up by the file.

My proposed fix:
stop zarafa
dump all of the databases with mysqldump (using the --opt parameter)
drop all of the databases.
shutdown mysqld
erase ibdata1,iblogfile0, and iblogfile1
edit my.cnf (see below)
restart mysql
restore the databases from the dumpfiles.

<---------------------------------------->
changes to my.cnf

[mysqld]
innodb_file_per_table
innodb_flush_method=O_DIRECT
innodb_log_file_size=1G
innodb_buffer_pool_size=4G
bulk_insert_buffer_size=256M

<-------------------------------->

The advantages:
I get my disk space back
I might cut down on the mysql thrashing
table optimize will actually work

The disadvantages:
Can anyone think of anything?

Note: the biggest change to the mysql config is moving tables out to individual files while leaving meta-data in ibdata1 getting rid of the ever growing database problem.

If there are no disadvantages,  I would suggest that the base install be modified similarly. Maybe add cleanup scripts to the nightly maint run.

« Last Edit: December 03, 2012, 05:11:02 am by half_life »

half_life

  • Bug Hunter
  • Zen Hero
  • *****
  • Posts: 867
  • Karma: +59/-0
    • View Profile
Re: Mysql database getting very large -- Zarafa related
« Reply #1 on: December 02, 2012, 08:55:00 pm »
It has been almost 24 hours and no one has offered any thoughts.  I am going to assume from this that my plan is at least plausible.  I will be doing this in the next few hours and report back with my initial results.

half_life

  • Bug Hunter
  • Zen Hero
  • *****
  • Posts: 867
  • Karma: +59/-0
    • View Profile
Re: Mysql database getting very large -- Zarafa related
« Reply #2 on: December 02, 2012, 11:47:20 pm »
This is looking good.  I recovered 40gb of disk space and mysqld is no longer using 140%-160% cpu (4 cpus assigned to the VM).  Zarafa webaccess is much quicker when searching.  The beauty of this is that I won't have to dump the databases again to clean up unused diskspace.  Using an optimize table command against the zarafa tables should deal with this in the future.  I can probably make this into a cron job and completely deal with the problem permanently.

While this probably deals with all of the database issues that I have been having lately,  I am still going to investigate using xtradb in a clustered mode instead of mysql on the zentyal server.

Graph of the zentyal server (via proxmox) shows the change in load on the server.
« Last Edit: December 03, 2012, 12:16:47 am by half_life »