> 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. Yes, I understand the 1 lock theory, but the problem symptoms were described to me as "disk thrashing". Disk thrashing is not a symptom I associate with a concurrency problem. > 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. Ah! This sounds more like the root of our immediate problem. Is there some way to cut down on the size of the mbox file? Can we archive more often as Ben suggests? > Yes, ezmlm handled the load without problem. Why did we switch? Mike