Yes Aaron but just notice, with 2.2x it didn't happen. I mean, the used space by the innodb tables, wasn't this huge like now.
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Aaron Stone > Sent: sábado, 2 de Agosto de 2008 22:53 > To: DBMail mailinglist > Subject: Re: [Dbmail] Db growing size > > As noted earlier, InnoDB table never get smaller, they just get more > organized :o > > 10 seconds is almost too fast... oh, looks like OPTIMIZE TABLE might > be what you need, not just ANALYZE. > > Based on some various web searching, it appears that InnoDB is not > very space efficient in general. Several blog posts I just read > indicate that InnoDB regularly uses 2-3x the space as the total of all > data in it -- overhead for all the indexing and write-ahead and > various other magic in Innodb. So that's actually consistent with what > you're seeing. Perhaps no bug and no optimization, just normal > behavior. > > Aaron > > > On Aug 2, 2008, at 1:32 PM, Jorge Bastos wrote: > > > Going to do that test. > > Dbmail-util -cy doesn't reduce the size of the db, in fact it run's > > in about > > 10 seconds > > > > > > > > > > > >> -----Original Message----- > >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On > >> Behalf Of Aaron Stone > >> Sent: sábado, 2 de Agosto de 2008 18:27 > >> To: DBMail mailinglist > >> Subject: Re: [Dbmail] Db growing size > >> > >> Jorge, > >> > >> You're cleaning out messages, but you're not reclaiming the table > >> space. > >> > >> In your first reply in this thread, you wrote: > >>> MySQL, > >>> Yes, nightly maintainance. > >>> --- > >>> /usr/local/sbin/dbmail-util -d -y > >>> /usr/local/sbin/dbmail-util -p -y > >>> /usr/local/sbin/dbmail-util -ty > >>> --- > >> > >> You need to run 'dbmail-util -c' as well, which runs an ANALYZE > TABLE > >> for each table. At this point, I recommend doing what everyone else > >> is > >> saying you should do, which is to see how an ANALYZE performs on a > >> _backup_ copy of your database. Find out how long your tables will > be > >> locked. Schedule a maintenance window on the real database once you > >> know how much time you need, and once you have a backup ready in > case > >> something goes wrong. > >> > >> Aaron > >> > >> > >> On Aug 2, 2008, at 8:38 AM, Jorge Bastos wrote: > >> > >>> Yes that that is not in case, 'cause i do maitainance. > >>> > >>> > >>>> -----Original Message----- > >>>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > >> On > >>>> Behalf Of Marc Dirix > >>>> Sent: sábado, 2 de Agosto de 2008 15:19 > >>>> To: DBMail mailinglist > >>>> Subject: Re: [Dbmail] Db growing size > >>>> > >>>>> Yes but i have quota for all users, unless me. > >>>>> So counting the maxmail_size for everyone, the db only could grow > >> up > >>>> to that value of 22GB, not 65GB > >>>>> > >>>> > >>>> This is not true, if you don't do maintainance. > >>>> (database, not dbmail) > >>>> _______________________________________________ > >>>> DBmail mailing list > >>>> DBmail@dbmail.org > >>>> https://mailman.fastxs.nl/mailman/listinfo/dbmail > >>> > >>> _______________________________________________ > >>> DBmail mailing list > >>> DBmail@dbmail.org > >>> https://mailman.fastxs.nl/mailman/listinfo/dbmail > >> > >> _______________________________________________ > >> DBmail mailing list > >> DBmail@dbmail.org > >> https://mailman.fastxs.nl/mailman/listinfo/dbmail > > > > _______________________________________________ > > DBmail mailing list > > DBmail@dbmail.org > > https://mailman.fastxs.nl/mailman/listinfo/dbmail > > _______________________________________________ > DBmail mailing list > DBmail@dbmail.org > https://mailman.fastxs.nl/mailman/listinfo/dbmail _______________________________________________ DBmail mailing list DBmail@dbmail.org https://mailman.fastxs.nl/mailman/listinfo/dbmail
