Scott
Further to my earlier post on this topic, I have taken a look at the
pipermail archiver code.
I concluded that there is a bug (or is it a feature?) which bloats the
size of the -article file in the pipermail database for each list.
This bloat will affect archiving performance,
At 9:29 PM -0500 2003/10/31, Scott Lambert wrote:
If we were talking about more than 10,000 files, I might buy it. But we
are talking about 1300 files.
Many filesystems start significantly slowing down around 1,000
files, not 10,000. Moreover, are you sure that this is the largest
number
I'm using Mailman 2.1.2 on FreeBSD v4.8-Release, built using the port. MTA
is sendmail 8.12.8p1
Very frequently I will see the ArchRunner process using 99+ % of cpu. I have
searched the archives and found lots of messages about qrunners using large
percentages of cpu, but they all seem to talk
Well you've pegged it. That was a bug in version 2.1.2 which is fixed
in 2.1.3. The patch for 2.1.2 should still be available - you could
probably patch your running system and just leave it at that (an upgrade
will bring the patch in anyway).
Good Luck - Jon Carnes
On Fri, 2003-10-31 at
On Fri, Oct 31, 2003 at 09:40:11AM -0500, Jon Carnes wrote:
On Fri, 2003-10-31 at 09:26, Jay West wrote:
I'm using Mailman 2.1.2 on FreeBSD v4.8-Release, built using the port. MTA
is sendmail 8.12.8p1
Very frequently I will see the ArchRunner process using 99+ % of cpu. I have
searched
On Friday, October 31, 2003, at 08:52 pm, Scott Lambert wrote:
On Fri, Oct 31, 2003 at 09:40:11AM -0500, Jon Carnes wrote:
On Fri, 2003-10-31 at 09:26, Jay West wrote:
I'm using Mailman 2.1.2 on FreeBSD v4.8-Release, built using the
port. MTA
is sendmail 8.12.8p1
Very frequently I will see the
On Fri, Oct 31, 2003 at 03:52:34PM -0500, Scott Lambert wrote:
Once I kill off the mailman queue runners and clean up the several lock
files for this mailing list, it runs just fine and manages to empty the
archive queue.
Well, the above statement is not entirely accurate. It was working
At 6:21 PM -0500 2003/10/31, Scott Lambert wrote:
I haven't looked at the code yet, and probably won't (ENOTIME), but it
almost sounds to me like it's not pruning it's list of handled messages
and has to walk all of them each time. I would have expected queue
handling to get faster as the
On Friday, October 31, 2003, at 11:59 pm, Brad Knowles wrote:
At 6:21 PM -0500 2003/10/31, Scott Lambert wrote:
I haven't looked at the code yet, and probably won't (ENOTIME), but
it
almost sounds to me like it's not pruning it's list of handled
messages
and has to walk all of them each
On Sat, Nov 01, 2003 at 12:59:24AM +0100, Brad Knowles wrote:
At 6:21 PM -0500 2003/10/31, Scott Lambert wrote:
I haven't looked at the code yet, and probably won't (ENOTIME), but
it almost sounds to me like it's not pruning it's list of handled
messages and has to walk all of them each
On Fri, 2003-10-31 at 21:29, Scott Lambert wrote:
On Sat, Nov 01, 2003 at 12:59:24AM +0100, Brad Knowles wrote:
At 6:21 PM -0500 2003/10/31, Scott Lambert wrote:
I haven't looked at the code yet, and probably won't (ENOTIME), but
it almost sounds to me like it's not pruning it's list of
11 matches
Mail list logo
