Date: Tue, 4 Apr 2000 19:19:00 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Kun Limfjordsporter <freebeer@fluffy.gets.an.analprobe.dk> Cc: current@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: FreeBSD random I/O performance issues Message-ID: <200004050219.TAA72439@apollo.backplane.com> References: <Pine.BSF.3.96.1000405025135.7687C-100000@fLuFFy.iNt.tElE.dK>
next in thread | previous in thread | raw e-mail | index | archive | help
: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
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200004050219.TAA72439>