Erik Kangas wrote:
Matthew B. Brookover wrote:
I have GFS up and running with UW-IMAP. Currently we are using the
mbox file format with version 2004g. We are looking at moving to MIX
some time next year. I have not done much MIX testing yet, but hope
to put it up on my test cluster when I have some time in December.
GFS is POSIX compliant. Flock, lock files, and fcntl locks work
across the cluster. Caches are kept synchronized, so a change to a
buffer on one node will show up in another. The biggest problem we
have had is when a user receives several hundred messages
simultaneously, the 3 mail servers will get hundreds of procmail
processes backed up waiting for the lock files.
We have a similar problem and it is not a function of GFS ... but any
system where each procmail needs a lock on the mailbox to deliver an
email. One solution we have been considering is having procmail
determine the number of already-running procmail processes for the
user in question. Above some thresshold, you could have procmail
issue an exit code that tells sendmail to shoot the messages into the
queue. This would potentially put some limit of the procmail
concurrency issue ... but the side effect is more overhead per message
delivery in general to detect this situation.
I wonder if anyone has a more clever solution (other then switching to
an email folder format or server that does not have this locking
issue in the first place).
Things that we have done at UVM to reduce (but not eliminate) some of
the locking contention with GFS and procmail/UW-IMAP:
- Keep the number of delivery nodes (the ones that run
sendmail/procmail) to a minimum. In our 6-node cluster, only 2 machines
are responsible for delivery, and they are used in order of MX
precedence, not round-robin. This reduces the amount of lock
"ping-ponging" between nodes.
- If a particular directory is going to have a large number of file
creations and deletions (e.g. /var/spool/mail, or wherever your c-client
locks are going) try to hash that directory out, possibly by several
levels deep, in order to reduce contention on directory locks. In
/var/spool/mail, we modified UW-IMAPd to hash that directory by the
first 2 letters of userid, e.g. mine is /var/spool/mail/j/t/jtl.
We haven't done anything to procmail other than for the /var/spool/mail/
directory hash. I'd be interested in hearing about it if anyone tries
Erik's suggestion about making procmail aware of its "peers" who are
delivering for the same user.
--
Jim Lawson
Technical Support Group, Enterprise Technology Services (formerly CIT)
The University of Vermont
Burlington, VT USA
_______________________________________________
Imap-uw mailing list
[email protected]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
