On Tue, Nov 23, 2004 at 02:28:43PM +0200, Ulf Pensar wrote:
We have an emailserver that we had to reboot the hard way a couple
of times a week.Now its a couple of time a day (perhaps because
the number of users have been growing)
[...]
the inetd generates root owned processes and
it doesnt stop before inetd is being killed. Then we have to reboot
the server to go on working.
if you really must run your imap server from inetd, then consider using xinetd
which allows limits on the number of simultaneous connections. or get rid of
uw-imapd junk and replace it with something better (see below)
I guess it is the webmail that is creating those imap-processes but
I'm not sure (could be imaps-clients of course).
Have you seen anything like that and what could be done?
Facts:
dell power edge 600 Sc, intel celeron 1,7 GHz, 2 GB ECC memory
running:
- woody (kernel compiled from debian package kernel-source-2.4.18)
fine so far.
fortunately, there's a lot you can do to help performance.
- uw-imap-ssl (starting from inetd)
replace with something sane. dovecot or courier-imapd for example.
dovecot works with mbox and Maildir mail boxes, courier-imapd only with
Maildir. you probably have mbox if you're running an old sendmail machine.
it's a trivial upgrade - "apt-get install dovecot".
btw, both dovecot and courier support both SSL encrypted and unencrypted
versions of the protocols. dovecot does pop & imap in the one package, while
courier has separate packages: courier-imapd and courier-popd.
- sendmail (with milter and clam)
replace with postfix. watch your mail transport related load vanish
instantly.
- bind, dhcp, mysql, radiusd-cistron (latest woody packages)
it kind of makes sense to have radius on your mail server, IF you are
authenticating against /etc/passwd.
dhcp, and mysql could be moved to other machines.
bind probably can't be moved without a lot of pain, if you have domains
delegated to this IP address. if you're just using it as a caching resolver,
then consider replacing it with something lighter - perhaps maradns or djbdns.
- webmail (the latest stable imp/horde)
- php-4.3.9
- imapproxy, just for the webmail (the latest)
imp doesn't have to run on the mail server.
consider moving these to another machine, perhaps your web server.
or consider using a different webmail program. imp is pretty heavy on
resources like memory. courier-sqwebmail is fairly light and integrates well
with the other programs in the courier suite, courier-maildrop, courier-imap,
etc. there are other lightweight ones around too, if you don't like sqwebmail.
other things you can do:
1. encourage people to delete mail from the server rather than leaving it on
there. you can do this by implementing quotas. start by setting a quota which
is several megabytes *above* the largest mailbox (i.e. the "unofficial,
temporary quota"). announce that you are setting a quota of what your eventual
target is (i.e. the "official quota"). gradually reduce the quota every week
until target is reached. don't tell your users how much leeway they have at
any given moment because they will abuse that knowledge. if they ask just tell
them the official quota and mention that some *unspecified* leeway is given for
a short *unspecified* time.
if you don't want to compile the kernel for quota support and install the quota
package, you can crudely simulate it for mailboxes with postfix's
'mailbox_size_limit' parameter. this is per mailbox file. imap users can get
around the quota by saving messages to different mailbox files.
alternatively, if you must allow users to have huge mailboxes, then:
2. switch to Maildir rather than mbox.
craig