Just the partlists and mimeparts weren't being cleaned out. The normal
tables cleaned in 2.2 were being cleaned, just not those new storage
system tables. Do make sure you backup all your data using mysqldump
before running it. I think it is fine to run but make no guarantee.
Also - the patch does not do the optimize table - just the delete's.
-Jon
Jorge Bastos wrote:
Hum... that must be it then, dbmail-util not deleting marked to be deleted
data!
Going to do my tests and let you know.
Paul, did you forgot dbmail-util to clean the new dbmail_mimeparts? :P
(I think Paul is on vacation, and he deserves!)
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Jonathan Feally
Sent: terça-feira, 12 de Agosto de 2008 21:39
To: DBMail mailinglist
Subject: Re: [Dbmail] Db growing size
I looked at the code for dbmail-util and the cleanup of the partlists
and mimeparts tables are not there. Thus your mimeparts will never be
cleared out of parts that are no longer in ues.
Run the normal dbmail-util -dy; dbmail-util -py; dbmail-util -cy to
clean out any messages pending db deletion and shrink the db files as
much as possible.
Then get a total byte count for the mail that is stored, and current
disk usage for the db.
Then run these queries in this order to remove part listings for
messages that have been purged, then to remove the parts that are no
longer referenced by the partlists.
DELETE dbmail_partlists.* FROM dbmail_partlists LEFT JOIN
dbmail_messages USING (physmessage_id) WHERE
dbmail_messages.message_idnr IS NULL;
DELETE dbmail_mimeparts.* FROM dbmail_mimeparts LEFT JOIN
dbmail_partlists ON (dbmail_mimeparts.id=dbmail_partlists.part_id)
WHERE dbmail_partlists.physmessage_id IS NULL;
OPTIMIZE TABLE dbmail_partlists;
OPTIMIZE TABLE dbmail_mimeparts;
Then report the current disk usage for the db after running these. It
should shrink quite a lot
I think that this will solve your issue. Attached is a hacked patch to
do these for you on a -py run. I have tested it with my 5.1 mysql
server, but not with sqlite or postgres.
Enjoy,
-Jon
Jorge Bastos wrote:
You're running into my major complaint about innodb. It never gives
space back. the file continues to grow until it uses all available
resources. I have heard about altering the storage engine to MyISAM
and then changing it back to get your disk space back, but I've never
tried it. running mysqloptimize will only make the file grow larger.
--------
That cannot be done, if I do it I'll lose foreign keys.(on
dbmail_mimeparts I could do it since it doesn't have any foreign
keys)
But yes, doing that will free space.
InnoDB table space, never goes back on file size, true, but, if I
only
have about 9GB of email, why the 53GB of size?
_______________________________________________
DBmail mailing list
DBmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail
--
This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.
_______________________________________________
DBmail mailing list
DBmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
_______________________________________________
DBmail mailing list
DBmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail
