[Kolab-devel] Multiple Kolab's php eat all the RAM

[Bernhard Reiter]

On Samstag, 27. Dezember 2008, Gunnar Wrobel wrote:
> Quoting "Diego M. Vadell" <dvadell at linuxclusters.com.ar>:
> > On Wednesday 24 December 2008 04:55:09 Alain Spineux wrote:
> >> On Tue, Dec 23, 2008 at 10:59 PM, Diego M. Vadell
> >>
> >> <dvadell at linuxclusters.com.ar> wrote:

> >> >   I think I found it: when I send an email to 30 people inside the
> >> > server (locals to the server) I get a lot of kolabmailfilter
> >> > processess. Is it the intended way of doing things?
> >>
> >> Unfortunately yes !

Not really.

The email transport system should be able to transport a single message
to several recipients as one message until the very end.
There have been several difficulties with this, so this ability
might be switched off until they are fixed.

> >> When you send to multiple recipients, one message is "cloned" by
> >> recipients ! This could be avoided by some more coding.
> >> This would reduce the CPU load and could reduce the space in the imap
> >> storage regarding
> >> the "singleinstancestore" in imapd.conf if handled
> >> appropriately.(divided by 3 with my own experience)

I do not recomment singleinstancestore on the imap backend,
as it might complicate backups and restores. Usually using group accounts
for account-less folders you can avoid too much double storage in the common 
cases. 


> >   I mitigated (or solved?) the issue by editing master.cf.template and
> > changing this line:
> >
> > kolabmailboxfilter     unix  -       n       n       -      -        pipe
> > user=kolab-n null_sender= argv=/kolab/bin/php
> >
> > to:
> >
> > kolabmailboxfilter     unix  -       n       n       -       2       pipe
> > user=kolab-n null_sender= argv=/kolab/bin/php
> >
> >
> > Given that amavisd gets only 2 emails at a time, I thought 2 was a good
> > place to start.
>
> I believe that is a sensible safeguard.
>
> @thomas, bernhard: Should we add this as a default?

[the technical solution should be followed up on kolab-devel at .]
It would limit kolabmailboxfilter startup, right?
2 sounds too low to me for the general case.
We should also find out why it takes up so much time to complete
or how much memory is eaten.

Bernhard

-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 206 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/devel/attachments/20090105/50279286/attachment.sig>