Thanks for your answer.
Please let me explain the situation here a bit in more detail, maybe the
reason for my question/the problem will become more clear and maybe someone
has an additional hint or better idea!
The system:
We have a mail server (IBM linux machine, with SuSE Linux), 16 CPU (Xeon
2,5GHz), 16 GB RAM, 500 GB RAID5 storage for mail (we have our users mail in
/home/mail/$username, users can not login to this host, just use it via imap
or pop) and another 500 GB RAID5 for /var/spool/mail, all file systems are
XFS.
The Problem:
Sometimes we were getting a load of up to 250 (!), thats when we kill some
all of the imapd deamons or have to reboot the machine. We are using
uw-imap, no ssl/tls (at the moment). The load immediatly goes down if we
kill enough imapd. During the high load the cpu usage is about 60 % idle,
the network traffic is normal but the disk i/o is near 100% all the time.
Thats why we thought of distributing the users folders on (for the first)
three independant RAID5 disk arrays to see if this really is the bottleneck.
Unfortunately this problem does not occure all the time :
- it has been seen mostly just before 6 pm, so it seems as everyone is
reading his email just before going home ... But not every day ...
- we have seen this while 60 users where using imap, and we have seen a load
of 4 if 300 users are connected
- there seems to be no real correlation between the problem and specific
users
- maybe one problem is the size of our users mailboxes, some (about 25) have
inboxes of over 1.5 GB (and refuse to change this, no way to solve this
here) and about additional 60 have more than 1 GB ... Don't know if this
causes a problem with imapd (uw-imap) but this is a point we can not change
...
All this indicates a problem with disk i/o throughput only, thats why we
want to try to distribute the users and i/o on different RAID systems (all
using XFS).
The links destinations in /var/spool/mail -> /var/mail02/rztest is owned by
rztest and its according group.
What i am wondering is:
1) where is /var/spool/mail/$username defined which procmail uses?
If i set "DEFAULT=/var/mail02/rztest" and refuse write permissions on
/var/spool/mail procmail actually works but i always get:
procmail[4025]: Couldn't rename bogus "/var/spool/mail/rztest" into
"/var/spool/mail/BOGUS.rztest.8uGN"
It seems that procmail first tries to rename the link and then reads
.procmailrc in the users home ... In the procmail logfile (defined with
VERBOSE=yes and LOGFILE="/tmp/procmail-rztest.log") there is no error
message at all.
2) is there a way to prevent procmail from checking if the default mailbox
is "bogus"?
3) how are you handling such problems?
4) about aufs: the homepage says it is still in development stage, do you
have experiance with aufs? Especially about stabilty and performance
(compared to XFS)?
Thanks in advance for your time and help!
With best regards
markus
Am 09.07.08 18:45 schrieb "Professional Software Engineering" unter
<PSE-L(_at_)mail(_dot_)professional(_dot_)org>:
At 14:45 2008-07-09 +0200, Markus Krause wrote:
We have to distribute the mailbox files of our (about 1200) users on our
mailserver to different hard discs. So we tried to set up soft links for
each user like
/var/spool/mail/a_user001 -> /var/lv01/a/a_user001
/var/spool/mail/b_user123 -> /var/lv02/b/b_user123
/var/spool/mail/x_user234 -> /var/lv04/x/x_user234
But now procmail thinks that these are bogus files, renames them to
something like BOGUS.a_user001.bg and creates a new INBOX file
/var/spool/mail/a_user001 which of course breaks our effort of
distributing the mailbox files on different disks.
Procmail does this if the file isn't owned by the correct user, isn't a
file or a directory, etc. It is based on the 'paranoid' code setting, and
there's only ONE place paranoid is set true (sometimes), and that's in
screenmailbox, where the following comment immediately preceeds the call
which eventually does the file tweak:
* check if the default-mailbox-lockfile is owned by the
* recipient, if not, mark it for further investigation, it
* might need to be removed
Out of curiosity, who owns the links?
From a system administration standpoint, more typically, one would
establish the entire /var/spool/mail (or /var/mail/) directory as a
mountpoint, or symlink the DIRECTORY to a mountpoint.
If you have a disk size issue, then the easy "real" - and fully transparent
- solution would involve using RAID to make up a single very large volume
from multiple disks and mount that as your mail spool.
Have you looked at the aufs union filesystem? Is it supported by the
distro you're using? (none of this is a matter for procmail though).
<http://aufs.sourceforge.net/>
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
____________________________________________________________
procmail mailing list Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail
____________________________________________________________
procmail mailing list Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail