From owner-freebsd-current Tue Apr 4 19:20: 2 2000 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id BB0BC37B8D1; Tue, 4 Apr 2000 19:19:56 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id TAA72439; Tue, 4 Apr 2000 19:19:00 -0700 (PDT) (envelope-from dillon) Date: Tue, 4 Apr 2000 19:19:00 -0700 (PDT) From: Matthew Dillon Message-Id: <200004050219.TAA72439@apollo.backplane.com> To: Kun Limfjordsporter Cc: current@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: FreeBSD random I/O performance issues References: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Woo. Okay, so I took the bait and snarfed the k0deZ from midday GMT :02.April, and have built a suitable SMP kernel and world, and that's :what I've been running for one news peering swerver for a spell. : :... : :As I noted in the earlier message I just sent, disabling the write- :behind via the sysctl knob didn't make an outstanding difference in :performance -- innd was still unresponsive during the time that the :random history database files needed updating for somewhere around :10 to 15 seconds when handling a full feed. I would have been very surprised if these changes made innd work better :-) These changes fix a case that innd does not usually generate. Even though innd's history files are hash-based, they are large enough that I would not expect one to typically hit the read-after-write case that the commit fixed. The innd problem is a different issue entirely, one related either to dirtying pages via mmap() or to excessive dirty pages in the buffer cache. You might be able to mitigate the problem somewhat by lowering the 'vfs.hidirtybuffers' sysctl, or maybe not. :I don't see any problems with the latest code changes (of 2 1/2 days :ago), as the machine has been running without problems for more than :a day now. I just don't see the improvement I am hoping for. This :machine isn't taking a full feed, but 2/3 of one, and it spends :on the order of 6 seconds blocked with disk activity every 30 secs. That's good. I didn't expect any problems with the write-behind fixes, they are fairly trivial. :I'm not quite sure, but it also seems like any access to this disk :(such as `ls -l /news') is blocked during the time the history files :on the disk are being updated -- similarly a seek with `less' within This is a different issue -- this is an issue of the disk write queues getting too long and/or the buffer cache getting starved and blocking other I/O while draining. :variable flow of news, but so far I don't see the improvement that :is needed for me to be able to keep up with a full incoming news :feed, which I do see on the companion box using NetBSD and trickle :sync, where the time INN spends on history file access drops to just :over a second out of every 5 minutes, compared with more than 100 :seconds using the current FreeBSD k0deZ. :... : :barry bouwsma, newsmangler & netscum -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message