We don't index attachments either. It's not a feature anyone had before Zimbra, so we figured no one would "miss" it, and we also figured it could be problematic (certainly in the early days of Zimbra 5.0, convertd, which is used for indexing, had its share of issues)
----- "Matt Mencel" <MR-Mencel@wiu.edu> wrote:
> Hi Steve,
>
> Do you use iostat to check your IOPS? Usage for us right now on INDEX
> looks like this...
>
> Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s
> avgrq-sz avgqu-sz await svctm %util
> sdd 0.06 10.80 2.12 3.53 35.01 114.66 17.51 57.33
> 26.48 0.01 2.45 0.88 0.49
>
> ...how do you find out what the "peak" IOPS are? Watch it during busy
> delivery times? I figured out how to generate the HTML reports with
> the zmtstat-chart command, perhaps it's in there...
>
> Do you index attachments? We turned off attachment indexing long ago
> and our delivery times improved quite a bit. Maybe that's why we are
> not seeing the latency problems you are/were?
>
> Matt Mencel
> Western Illinois University
>
>
>
> ----- Original Message -----
> From: "Steve Hillman" <hillman@sfu.ca>
> To: "zimbra-hied-admins" <zimbra-hied-admins@sfu.ca>
> Sent: Monday, March 23, 2009 4:22:37 PM GMT -06:00 US/Canada Central
> Subject: Batched Indexing in Zimbra
>
> I just want to take a moment to share a little piece of recently
> gained knowledge with you. If you don't already know about Zimbra's
> Batched Indexing feature, *turn it on*! This feature isn't on by
> default yet, but it makes a *huge* difference to performance. It is
> documented in the Zimbra Large Site Performance Wiki page.
>
> The feature is enabled on a per-COS basis, presumably to allow you to
> group your users based on their need for mailbox indexing, and tune
> the value appropriately. It can be set on all COS's with this shell
> command:
>
> for cos in `zmprov gac`; do zmprov mc $cos zimbraBatchedIndexingSize
> 20; done
>
> The "zimbraBatchedIndexingSize" value is the number of unindexed
> messages that must accumulate in a mailbox before they'll be indexed.
> If the owner of a mailbox does a text search while there are unindexed
> messages in the mailbox, all unindexed messages will be indexed on the
> spot, so there's no danger of messages being missed in search
> results.
>
> Essentially what this feature does is decouple message delivery from
> indexing, making them asynchronous. Until last Friday, we were having
> serious interactive performance issues whenever a message was sent to
> a substantial number of users (which isn't hard in a university
> environment). The I/O load spike would saturate the disks enough that
> all transactions would be affected -- especially sending messages from
> the web client. We'd see periods of 10-20 second delays while trying
> to send a message or save a draft. In addition, LMTP throughput wasn't
> great -- the graphs produced by zmstat-chart showed peak delivery
> rates of maybe 6-7 messages per second, with latency climbing to over
> 15 seconds (i.e 15 seconds to deliver a message) during that time.
>
> Once we made the change, it's like we're looking at completely
> different servers. We now see LMTP peak delivery rates of 20+
> msgs/second per mailbox server (and I suspect it can go higher - we
> just haven't had any really large mailouts since Friday) with latency
> peaking at 1 second. And interactive latency has dropped to under a
> second for sending. The peak disk I/O load has dropped from 80-100%
> busy to 20% busy. IOPS on the Index volume have gone from 1000+ peak
> iops to 100.
>
> --
> Steve Hillman IT Architect
> hillman@sfu.ca IT Infrastructure
> 778-782-3960 Simon Fraser University
--
Steve Hillman IT Architect
hillman@sfu.ca IT Infrastructure
778-782-3960 Simon Fraser University