Quoting Mike Bresnahan (mbresnah at visi.com): > > Instead of throwing more hardware at it, how about a software > > solution. Carl > > posted why mailman's archiving sucks. How about some of you > > Python guru's "fix" > > the performance issues? > > Unless I'm missing something, Carl's diagnosis does not explain why the box > is I/O bound. If the problem was caused by a concurrency issue as he > suggests, the box and/or disks would be not be fully loaded. The is a concurrency issue. 1 mbox file for the archive, only one instance (be a thread or process) can access the mbox at a time. Pipermail does file level locking so that is a concurrecy issue. Next because the mbox file is getting large, almost 2Gb now, there is a problem that pipermail wants to load the entire mbox into core. 128Mb swap + 512Mb swap < 2.0Gb file, so the disk thrash. Swaping, swaping, swapping. Since the file is only getting bigger, we can put more RAM (Nate is looking into it), but eventually, well hit the motherboard limit, so we need faster disks to handle the swapping. > > As an aside, we are not the only group feeling the pinch. Lots of > > talk about > > performance problems, scalability of mailman on the mailman > > developer list. > > So you blame the problem on mailman; not on an overworked box? Yes, ezmlm handled the load without problem. > I'd be happy to help with such an effort if a decent solution does not > already exist. Are there not alternatives to mailman? Many alternatives to mailman, but mailman has the best user interface. -- Minneapolis St. Paul Twin Cities MN | Phone : (952)943-8700 http://www.mn-linux.org Minnesota Linux | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9