Cyrus 2.3.8 thanks for help

[Simon Matter]

> We had several other universities called and offered assistance.
>
> Thanks!
>
> We also had several people call with offers to help with consulting
> on it, but mostly not at the same level of Cyrus hardware/software/config
> we are running.  We appreciate the effort though, we really do.  Lots of
> folks seem to run mail-stores in the 5K-10K user range, not too many
> trying to stuff 30K users onto one that we have talked to so far.

Comparing user numbers is difficult because the usage pattern can be quite
different. Corporate users, like in most of my cases, are pushing a server
much harder than others because 80% to 90% of them are active during
working hours. Another factor is the size per user, having users with
quota in the gigabyte range simply puts more load on the server than those
with smaller mailboxes.

>
> We are still struggling with some slowness on the system and trying to
> refine our setup.   Probably we are trying to do too much at once.
>
> Our setup:
> Cyrus 2.3.8 + FastMail patches
> Sun T2000, 16 gigs RAM, Solaris 10u3
> 2 3510FC arrays using Sun MultiPath
> ZFS mirrored pools across the 2 arrays (expensive but safe)
> ZFS snapshots for 14 days
>
> We have cut down LMTP maxchilds to 200 then 150 seems to
> be helping with locking issues.  I think we also have other issues
> such as doing sendmail on the mail-stores instead of LMTP, and
> we realize now we compiled SASL with /dev/random.  Ken replied
> that we should turn up logging to DEBUG haven't found where to
> do to that just yet hopefully tomorrow.

First we don't have much info on your exact config. Maybe you want to
share some of your config details so people can better suggest what to
try. Here is a list of things I try to do to keep a server fast:

- as said before, use /dev/urandom instead of /dev/random.
- set expunge_mode: delayed which greatly reduces load in certain situations
- try to avoid slow authentication and authorization. For example
resolving large groups in LDAP without caching them can slow things down.
- put your partition-* on separate filesystems
- put your configdirectory on a separate filesystem and possibly on
separate spindles and on a conventional filesystem

additional things to try:

- try using metapartition
- check your database configs, at least for me using skiplist for all
databases which are berkeley by default has made some problems we had
before dissapear
- try to make sure that you don't slow down your filesystems by using
things like snapshots on the OS level. Depending on their implementation
they can slow down things. However I don't know much about ZFS and maybe
you do it on the FC arrays anyway.

Regards,
Simon