From owner-freebsd-hackers  Mon Feb  5 17: 2: 9 2001
Delivered-To: freebsd-hackers@freebsd.org
Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67])
	by hub.freebsd.org (Postfix) with ESMTP id E624B37B69D
	for <freebsd-hackers@FreeBSD.ORG>; Mon,  5 Feb 2001 17:01:51 -0800 (PST)
Received: (from dillon@localhost)
	by earth.backplane.com (8.11.1/8.9.3) id f1611Zu55025;
	Mon, 5 Feb 2001 17:01:35 -0800 (PST)
	(envelope-from dillon)
Date: Mon, 5 Feb 2001 17:01:35 -0800 (PST)
From: Matt Dillon <dillon@earth.backplane.com>
Message-Id: <200102060101.f1611Zu55025@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
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>
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

    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