Re: Performance issues with Zimbra 6?

[Rich Graves <rgraves@carleton.edu>]

I saw performance problems in a similar virtual clone, which were not present in 5.0.18, but the problem was not quite as severe as you describe. For me, only the first login per mailboxd restart was slow.

Maybe our storage is significantly faster, or my Xen build is more efficient than whatever virtualization you're running.

I don't see login-time performance problems on a running production server. We do see stalls opening or deleting messages that I attribute variously to db/data storage latency that also affects other SAN users (new batch of disks arriving tomorrow) or gratuitous toasting (bugzilla 45473, unfortunately deferred to 6.0.7).

>  - deleting all shared and remote calendars (had to do this directly in mysql because zmmailbox times out)

Details? I've long been curious where sharing data are stored.

> It seems Zimbra has reverted to instantiating the calendar data at login time, rather than waiting until the Calendar tab is selected. 

Interesting. Yeah, I see that hover-over-minicalendar works immediately on testzimbra.com. My 6.0.4 installation works like 5.0.18 -- lots of things break until you either load the calendar tab or create a new appointment.

If this change is still present when we move to 6.0.6, I'll have some happy users. If anyone can find a bugzilla confirming this was intended, let me know.

Mitigation:

When we upgraded production to 6.0.4 last December, I ran

libexec/scripts/optimizeMboxgroups.pl (added about 50 minutes of downtime for 3500 users, with 34GB worth of db/data on a midrange SAN)

I might also have piped "sm $user" for each user to zmmailbox -z, to prime caches, but bugzilla 35688 did that for me. :-(

You'll also need to reindex every single mailbox after a ZCS 5->6 upgrade, unless this bug is fixed.
http://bugzilla.zimbra.com/show_bug.cgi?id=44191
-- 
Rich Graves http://claimid.com/rcgraves
Carleton.edu Sr UNIX and Security Admin
CMC135: 507-222-7079 Cell: 952-292-6529