-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jul 2, 2008, at 11:15 PM, Mark Sapiro wrote:
Yes, I know. I was just about to resend. It is attached here. The
MUA I
used to send the previous message gives any attachment without an
extension Content-Type: application/octet-stream, so the list
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Barry Warsaw wrote:
| On Jul 2, 2008, at 11:01 PM, Mark Sapiro wrote:
|
|> The attached 'post' file is a modified version of scripts/post.
|
| Hi Mark, there was no attachment.
Yes, I know. I was just about to resend. It is attached here. The MUA I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jul 2, 2008, at 11:01 PM, Mark Sapiro wrote:
The attached 'post' file is a modified version of scripts/post.
Hi Mark, there was no attachment.
It does the following compared to the normal script.
The normal script reads the message from the
Fletcher Cocquyt wrote:
>
>On 7/2/08 8:15 AM, "Mark Sapiro" <[EMAIL PROTECTED]> wrote:
>
>> At some point in the next day or so, I'm going to make a modified
>> scripts/post script which will queue incoming messages in qfiles/bad
>> and then move them to qfiles/in only if they are under a certain s
Fletcher Cocquyt wrote:
>Interesting, the growth per python is limited to 50M by ulimit -v 5, but
>I'm seeing each one gradually take up that limit - then what ? (stay tuned!
>- mailman fails to malloc?)
Look in Mailman's error and qrunner logs.
--
Mark Sapiro <[EMAIL PROTECTED]>Th
Interesting, the growth per python is limited to 50M by ulimit -v 5, but
I'm seeing each one gradually take up that limit - then what ? (stay tuned!
- mailman fails to malloc?)
load averages: 0.14, 0.11, 0.11
10:14:43
120 processes: 119 sleeping, 1 on cpu
CPU states: 93.9% idle, 3.7% user,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jul 2, 2008, at 1:12 PM, Fletcher Cocquyt wrote:
I am hopeful our esteemed code maintainers are thinking the built in
restart
idea is a good one:
Optionally, yes. By default, I'm not so sure.
- -Barry
-BEGIN PGP SIGNATURE-
Version:
I am hopeful our esteemed code maintainers are thinking the built in restart
idea is a good one:
BW wrote:
>> Or is there not a way expire & restart mailman processes analogous
>> to the
>> apache httpd process expiration (designed to mitigate this kind of
>> resource
>> growth over time)?
>
>
> b
Fletcher Cocquyt wrote:
Or is there not a way expire & restart mailman processes analogous to the
apache httpd process expiration (designed to mitigate this kind of resource
growth over time)?
You can do "mailmanctl restart", but that's not really a proper solution to
this problem.
--
Brad
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jul 2, 2008, at 11:15 AM, Mark Sapiro wrote:
At some point in the next day or so, I'm going to make a modified
scripts/post script which will queue incoming messages in qfiles/bad
and then move them to qfiles/in only if they are under a certain s
Last night I added
ulimit -v 5
To the /etc/init.d/mailman script and restarted
And I am seeing the processes stop growing at 49M - and so far no adverse
affects.
I view this as a workaround until the underlying cause is determined...
But it also allows me to bump my incoming runners from 8
On 7/2/08 8:15 AM, "Mark Sapiro" <[EMAIL PROTECTED]> wrote:
> Fletcher Cocquyt wrote:
>
>> I did a test - I disabled the SpamAssassin integration and watched the heap
>> grow steadily - I do not believe its SA related:
>
>
> OK.
>
> Does your MTA limit the size of incoming messages? Can it?
Fletcher Cocquyt wrote:
>I did a test - I disabled the SpamAssassin integration and watched the heap
>grow steadily - I do not believe its SA related:
OK.
Does your MTA limit the size of incoming messages? Can it?
At some point in the next day or so, I'm going to make a modified
scripts/post s
Back at the beginning of this thread, Fletcher Cocquyt wrote:
Config:
Solaris 10 x86
Python 2.5.2
Mailman 2.1.9 (8 Incoming queue runners - the leak rate increases with this)
SpamAssassin 3.2.5
At this point I am looking for ways to isolate the suspected memory leak - I
am looking at using dtr
I did a test - I disabled the SpamAssassin integration and watched the heap
grow steadily - I do not believe its SA related:
[EMAIL PROTECTED]:mailman-2.1.9 10:51pm 68 # pmap 22804 | egrep heap
08175000 14060K rwx--[ heap ]
[EMAIL PROTECTED]:mailman-2.1.9 10:51pm 69 # pmap 22804 | egrep heap
On 7/1/08, Fletcher Cocquyt wrote:
Fletcher Cocquyt
Senior Systems Administrator
Information Resources and Technology (IRT)
Stanford University School of Medicine
BTW, in case it hasn't come through yet -- I am very sensitive to
your issues. In my "real" life, I am currently employed as
On 7/1/08, Mark Sapiro wrote:
In this snapshot
PID USERNAME LWP PRI NICE SIZE RES STATETIMECPU COMMAND
10123 mailman1 590 314M 311M sleep1:57 0.02% python
10131 mailman1 590 310M 307M sleep1:35 0.01% python
10124 mailman1 590 309M 78
On 7/1/08, Fletcher Cocquyt wrote:
Pmap shows its the heap
[EMAIL PROTECTED]:in 8:08pm 64 # pmap 24167
24167:/bin/python /opt/mailman-2.1.9/bin/qrunner
--runner=IncomingRunner:5:8
08038000 64K rwx--[ stack ]
0805 940K r-x-- /usr/local/stow/Python-2.5.2/bin/python
08
On 7/1/08, Mark Sapiro wrote:
In any case, I know you're reluctant to just let it run, but I think if
you did let it run for a couple of days that the IncomingRunners
wouldn't get any bigger than the 310 +- MB that you're already seeing
after 3 hours, and the rest of the runners would remain
Fletcher Cocquyt wrote:
>Pmap shows its the heap
>
>[EMAIL PROTECTED]:in 8:08pm 64 # pmap 24167
>24167:/bin/python /opt/mailman-2.1.9/bin/qrunner
>--runner=IncomingRunner:5:8
>08038000 64K rwx--[ stack ]
>0805 940K r-x-- /usr/local/stow/Python-2.5.2/bin/python
>0814A000 1
Pmap shows its the heap
[EMAIL PROTECTED]:in 8:08pm 64 # pmap 24167
24167:/bin/python /opt/mailman-2.1.9/bin/qrunner
--runner=IncomingRunner:5:8
08038000 64K rwx--[ stack ]
0805 940K r-x-- /usr/local/stow/Python-2.5.2/bin/python
0814A000 172K rwx-- /usr/local/stow/Python
Mark Sapiro wrote:
Which processes correspond to which runners. And why are the two
processes that have apparently done the least the ones that have grown
the most.
and
What are these last 2? Presumably they are the missing NewsRunner and
RetryRunner, but what is the extra stuff in the ps ou
Fletcher Cocquyt wrote:
>
>Here is the current leaked state since the the cron 13:27 restart only 3
>hours ago:
>last pid: 20867; load averages: 0.53, 0.47, 0.24
>16:04:15
>91 processes: 90 sleeping, 1 on cpu
>CPU states: 99.1% idle, 0.3% user, 0.6% kernel, 0.0% iowait, 0.0% swap
>Memory:
On 7/1/08 3:37 PM, "Mark Sapiro" <[EMAIL PROTECTED]> wrote:
> Fletcher Cocquyt wrote:
>
>> Not finding a "leak" ref - save a irrelevant (for this runner issue) admindb
>
>
> Nothing has been done in Mailman to fix any memory leaks. As far as I
> know, nothing has been done to create any eith
Fletcher Cocquyt wrote:
>Not finding a "leak" ref - save a irrelevant (for this runner issue) admindb
Nothing has been done in Mailman to fix any memory leaks. As far as I
know, nothing has been done to create any either.
If there is a leak, it is most likely in the underlying Python and not
a
Not finding a "leak" ref - save a irrelevant (for this runner issue) admindb
one:
[EMAIL PROTECTED]:mailman-2.1.11 1:26pm 58 # ls
ACKNOWLEDGMENTS Mailman README-I18N.enSTYLEGUIDE.txt
configure doc misc templates
BUGS Makefile.in
>I'm having a hard time finding the release notes for 2.1.11 - can you please
>provide a link?
>(I want to see where it details any memory leak fixes since 2.1.9)
>Fletcher Cocquyt
>Senior Systems Administrator
>Information Resources and Technology (IRT)
>Stanford University School of Medicine
The
I'm having a hard time finding the release notes for 2.1.11 - can you please
provide a link?
(I want to see where it details any memory leak fixes since 2.1.9)
thanks
On 7/1/08 10:09 AM, "Vidiot" <[EMAIL PROTECTED]> wrote:
>> Solaris 10 x86
>> Python 2.5.2
>> Mailman 2.1.9 (8 Incoming queue run
>Solaris 10 x86
>Python 2.5.2
>Mailman 2.1.9 (8 Incoming queue runners - the leak rate increases with this)
>SpamAssassin 3.2.5
>
>At this point I am looking for ways to isolate the suspected memory leak - I
>am looking at using dtrace: http://blogs.sun.com/sanjeevb/date/200506
>
>Any other tips ap
An update - I've upgraded to the latest stable python (2.5.2) and its made
no difference to the process growth:
Config:
Solaris 10 x86
Python 2.5.2
Mailman 2.1.9 (8 Incoming queue runners - the leak rate increases with this)
SpamAssassin 3.2.5
At this point I am looking for ways to isolate the su
30 matches
Mail list logo
