Date: Mon, 5 Feb 2001 17:01:35 -0800 (PST) From: Matt Dillon <dillon@earth.backplane.com> To: Alfred Perlstein <bright@wintelcom.net> Cc: Jos Backus <josb@cncdsl.com>, Dan Phoenix <dphoenix@bravenet.com>, freebsd-hackers@FreeBSD.ORG Subject: Re: qmail IO problems Message-ID: <200102060101.f1611Zu55025@earth.backplane.com> References: <20010205135501.H26076@fw.wintelcom.net> <Pine.BSO.4.21.0102051409200.18264-100000@gandalf.bravenet.com> <20010205162938.A50388@lizzy.bugworks.com> <20010205165023.L26076@fw.wintelcom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
I think before you guys go off wandering you need some definitive
information on the rate of incomming and outgoing mail, number of
simultanious connections being handled, and so forth.
On the face of it, high disk transaction rates, low transfer rates,
and idle cpu implies either lots of paging I/O or softupdates isn't
actually turned on.
Lots of paging I/O implies, potentially, lots of connections. So you
need a couple of stats in-hand to figure out what is going on:
* How many mail-related processes are running, and by inference how
many simultanious connections are being handled?. 'ps axlww' while
the heavy I/O is going on would help a lot here.
* Is the sytem paging? 'systat -vm 1' will give you a good indication.
* 'vmstat 1' output also helps
If the system is running too many processes then some messing around
with qmail's configuration options should solve the problem.
Also, nowhere did I read how much memory this machine had. This will
give us useful information on that front:
* cat /var/run/dmesg.boot
(And, for gods sake, DON'T screw around with sysctl vfs.write_behind! I
should probably just rip that sysctl out. The default heuristic handles
all the cases already).
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200102060101.f1611Zu55025>