Developers of Sympa

[Olivier Salaun - CRU <address@concealed>]

Hi Sergiy,

Sergiy Zhuk wrote:

> We are aware of memory leaks in Sympa processes aparently linked to the
> number of lists and/or subscribers.
>   
I've found an additional cause of intensive memory use - digests.
The sympa process was dying for several hours in a raw growing up to allowed limit (512Mb) every time.
Then I've discovered that it's trying to send a digest which was more than a Gigabyte in size (lots of pictures).

1 Gb digest are rare, aren't they ?
Maybe we could add a parameter to limit the size of a digest. But how
should we send the remaining hundreds of Mb to subscribers ?

It was trying to read the whole thing into memory. I've figured if sympa is doing it for every digest and is not freeing the memory after that, it would cause an excessive memory use.

We have to check that ; if you're right it would explain part of the
memory leeks...
Sympa 4.0 uses a different code for sending digests (using a template)
; hopefully it will be better in freeing memory afterward...

Another problem is sympa queue processing. You can only have one process (sympa.pl) processing the queue and that is definitely not enough in case you have high traffic volume lists.
AFAIR sympa always sorts the queue by the list name, so it doesn't give other lists a chance if you have a 1,000 messages waiting for delivery for the same list.

1000 messages is a lot for a single list ; any subscriber in this list
;-) ?
You can use the list priority parameter to cope with this ; list config
are reloaded whenever they change.
You can either set this list's priority to 'z' (remain in spool) or
increase other list priority.
-- 
Olivier Salaun
Comite Reseau des Universites