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
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
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
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?
No, Yes
#
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
-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
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
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)?
bin/mailmanctl
-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-
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%
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]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 size.
I'm
-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
-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: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
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
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
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 runners -
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
There
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
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
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 either.
Ok,
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: 1640M
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
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--
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 172K
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
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
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
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 a
30 matches
Mail list logo
