Mailing List Archive

Redux: Re: Memory issues with pgsql interface
No, however I have come across the same behavior with the mysql interface
and a mailing list of similar size.

My investigation indicated that it was only when the queue runner tried to
do a delivery attempt on that specific message that the problem occurred.

Was this investigated? Is there a fix?



On Fri, 19 Oct 2001, Gavin Sherry wrote:

> Hi all,
>
> I decided to run a mailing list of about 7000 people out of postgres with
> Exim. I was quite surprised when queue runners were picking up the message
> and using memory like this:
>
> exim 566 8.6 6.5 289996 33820 ? S 10:49 0:27 /usr/exim/bin/exim -qq
>
> Has anyone come across this kind of thing when using the pgsql interface?
>
> Gavin
>
>
> --
> ## List details at http://www.exim.org/mailman/listinfo/exim-users Exim details at http://www.exim.org/ ##
>

--
Jawaid Bazyar | Affordable WWW & Internet Solutions
foreThought.net | for Small Business
jawaid.bazyar@foreThought.net | 910 16th Street, #1220 (303) 228-0070
--The Future is Now!-- | Denver, CO 80202 (303) 228-0077 fax
Re: Redux: Re: Memory issues with pgsql interface [ In reply to ]
On Thu, 11 Jul 2002 Jawaid.Bazyar@foreThought.net wrote:

> No, however I have come across the same behavior with the mysql interface
> and a mailing list of similar size.
>
> My investigation indicated that it was only when the queue runner tried to
> do a delivery attempt on that specific message that the problem occurred.
>
> Was this investigated? Is there a fix?

Which release of Exim?

> On Fri, 19 Oct 2001, Gavin Sherry wrote:

Can't have been later than 3.33. There was this fix for 3.32, which
could be relevant:

6. If a delivery in a subprocess (local or remote) opened a connection to (for
example) an MySQL server, that connection never got properly closed because the
cleanup function was called only in the main process. Calls to the tidyup
function have been added to the subprocesses.



--
Philip Hazel University of Cambridge Computing Service,
ph10@cus.cam.ac.uk Cambridge, England. Phone: +44 1223 334714.
Re: Redux: Re: Memory issues with pgsql interface [ In reply to ]
Philip,

Ok, I'm running 3.16.

This mysql connection thing - would a connection be made (and not closed)
once per sub process? If just once, I don't see how that could cause the
exim process in question to grow to 250M.

Last night I worked around the problem by using the "exim -bs" trick and
breaking the delivery of the list up into 100-user chunks. That has other
benefits besides avoiding the mysql memory issue.

Jawaid

--

On Thu, 11 Jul 2002, Philip Hazel wrote:

> On Thu, 11 Jul 2002 Jawaid.Bazyar@foreThought.net wrote:
>
> > No, however I have come across the same behavior with the mysql interface
> > and a mailing list of similar size.
> >
> > My investigation indicated that it was only when the queue runner tried to
> > do a delivery attempt on that specific message that the problem occurred.
> >
> > Was this investigated? Is there a fix?
>
> Which release of Exim?
>
> > On Fri, 19 Oct 2001, Gavin Sherry wrote:
>
> Can't have been later than 3.33. There was this fix for 3.32, which
> could be relevant:
>
> 6. If a delivery in a subprocess (local or remote) opened a connection to (for
> example) an MySQL server, that connection never got properly closed because the
> cleanup function was called only in the main process. Calls to the tidyup
> function have been added to the subprocesses.

--
Jawaid Bazyar | Affordable WWW & Internet Solutions
foreThought.net | for Small Business
jawaid.bazyar@foreThought.net | 910 16th Street, #1220 (303) 228-0070
--The Future is Now!-- | Denver, CO 80202 (303) 228-0077 fax
Re: Redux: Re: Memory issues with pgsql interface [ In reply to ]
On Thu, 11 Jul 2002 bazyar@hypermall.com wrote:

> Ok, I'm running 3.16.
>
> This mysql connection thing - would a connection be made (and not closed)
> once per sub process? If just once, I don't see how that could cause the
> exim process in question to grow to 250M.

Seems a bit odd, that's true. However, there have been other problems
that ate memory, and which have been fixed in later releases.


--
Philip Hazel University of Cambridge Computing Service,
ph10@cus.cam.ac.uk Cambridge, England. Phone: +44 1223 334714.