On Tue, 2002-01-29 at 23:54, Mike Bresnahan wrote: > 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. blocking on I/O in this case is more a contention issue and not a high I/O load "disk thrashing" issue. They're waiting for the lock to be released for their turn i think. > > 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 > > > _______________________________________________ > Twin Cities Linux Users Group Mailing List - Minneapolis/St. Paul, Minnesota > http://www.mn-linux.org > tclug-list at mn-linux.org > https://mailman.mn-linux.org/mailman/listinfo/tclug-list > -- Ben Lutgens http://people.sistina.com/~blutgens/ System Administrator Sistina Software Inc. "If you love someone, set them free. If they come home, set them on fire." - George Carlin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: This is a digitally signed message part Url : http://shadowknight.real-time.com/pipermail/tclug-list/attachments/20020129/60496a00/attachment.pgp