[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: zmdbintegrityreport
Our site had been running it for years without a noticeable impact on performance. In June we changed the servers out with more ram/cpu cores. We basically presented the SAN luns to newer hardware and ran an upgrade on top of the existing installs.
Ever since then, the dbintegrity report has had a noticeable impact to the point that mail is almost unusable. We have been investigating it since then to see why it's now an issue after upgrading to faster hardware. I know that Zimbra's stance is to disable it if performance is impacted but we want to know why we were able to run it previously without any sort of issue.
If we aren't able to determine why, we'll either be scheduling it for once a month or disabling it all together.
Thanks,
Doug
----- "Amos" <a.goo0h@gmail.com> wrote:
> From: "Amos" <a.goo0h@gmail.com>
> To: "zimbra-hied-admins" <zimbra-hied-admins@sfu.ca>
> Sent: Monday, September 13, 2010 12:21:40 PM GMT -05:00 US/Canada Eastern
> Subject: Re: zmdbintegrityreport
>
> Hmm... overlooked this previously.
>
> http://www.zimbra.com/docs/os/latest/administration_guide/C_CronTab%20Jobs.14.3.html#1059012
>
> So what have some of the larger sites on here done?
>
>
> On Mon, Sep 13, 2010 at 10:24 AM, Amos <a.goo0h@gmail.com> wrote:
> > When are folks running zmdbintegrityreport? I realize it's
> important
> > to run, but gosh, server becomes pretty much unusable when it's
> > running. Looking at
> >
> http://wiki.zimbra.com/wiki/Performance_Tuning_Guidelines_for_Large_Deployments#MySQL
> > I notice our my.cnf is already at those levels, so hesitant to
> raise
> > anything much further. Not sure how much that would help with
> > zmdbintegrityreport anyway.
> >
> > By default zmdbintegrityreport runs Sunday nights, but that tends
> to
> > be a peak time for us. So I tried Saturday night, and now a
> professor
> > complained. I hate to run it while zmbackups are running, but may
> > have to. Maybe just during an incremental the contention won't be
> so
> > bad.
> >
> > Yeah, we need to split things out onto more servers, but doing so
> > rather gradually. This is on a Sun B8000 blade with quad, quad
> core
> > AMD chips. Probably could use some more memory.
> >
> > Memory: Total Used Free Shared Buffers
> > Mem: 32942652 32718860 223792 0 1244704
> > Swap: 8393848 36180 8357668
> >
--
Doug Curtis
doug.curtis@oit.gatech.edu
Georgia Tech OIT/A&I
404.385.0390