A Cyrus/murder of that size is possible?

Henrique de Moraes Holschuh hmh at debian.org
Sat Sep 6 14:40:51 EDT 2003


On Sat, 06 Sep 2003, Sergio Devojno Bruder wrote:
> Ok, no problem. Something around the end of the year, I think.

Can you disclose whom will be deploying such a system?

> >> I never saw any published benchmarks|comparitions of
> >> cyrus with MTAs doing local delivery by lmtp|smtp.
> >
> >That's because it is hugely dependent on your system. I believe 15 emails
> >per second is possible, but you need:
> >  1. Extremely well tunned storage (big caches, etc)
> >  2. XFS or another very fast journaled filesystem.
> 
> I was thinking about the infamous ext3 data=journal. XFS is better 
> than that (for MTAs)?

Yes, in my experience it is. Ext3 is pityful when compared to XFS for Cyrus
(and posfix) spools, and other data areas. I got a >3x speed increase in my
servers when I switched from ext3 (2.4.18 days, data=journal was broken at
that time) to xfs.  Ext3 is better nowadays, but still...

> >>- Using storage with fiber in my ia32 backend servers, how much
> >
> >ia32? Which unix will you run on them? Some flavour of Linux, of the BSDs,
> >or Solaris?
> 
> Linux.

Then, I suggest you don't compile from unpatched source.  Use either Debian
with my packages, or Simon's RPMs.  IMHO anyway ;-)

> >It should be possible.  You'd need to either:
> > 1. create a mupdate "table engine" and perform mupdate mailbox
> >    lookups in the transport table, OR
> > 2. create a new version of the lmtp transport that is mupdate-aware.
> >
> >(2) above looks doable.  If you do so, I would very much like to see
> >that code in either cyrus contrib, postfix contrib, or even postfix
> >upstream...
> 
> In the postfix way-of-things the more tradicional way is the first 
> one, but I'm inclined exactly to your second sugestion.
> 
> >Anyway, you can easily run Cyrus lmtp muder proxies in every postfix box,
> >so that would not be a bottleneck.
> 
> This is a third option that I will pursuit if the postfix 
> modification gets complex or 'dirty'.

IMHO you should do it first.  It is probably just as fast, if not faster,
and it will always be in sync with the rest of Cyrus' mupdate protocol
services.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh




More information about the Info-cyrus mailing list