Date: Wed, 5 Apr 2000 03:28:45 +0200 (CEST) From: Kun Limfjordsporter <freebeer@fluffy.gets.an.analprobe.dk> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: current@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: FreeBSD random I/O performance issues Message-ID: <Pine.BSF.3.96.1000405025135.7687C-100000@fLuFFy.iNt.tElE.dK> In-Reply-To: <fa.kfq319v.1bnaii2@ifi.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 2406 Sep 1993, Matthew Dillon wrote:
> I've committed an 80% fix for the random seek / write
> performance issue. The rest of the fix will come later
> when Kirk commits his shared-lock-buffer-cache idea.
>
> I've committed it into -current and will MFC it into
> -stable in a week if there aren't any problems. I
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.
> This should solve most of the random-I/O latency issues
> with read-after-write on buffers. Basically what
> had to be done was to continue to call the clustering
> code as before (so reallocblks still gets called), but
> only issue write_behind I/O if the writes are
> generally sequential. If the writes are random, even
> big writes, we do not issue write-behind I/O.
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.
Unfortunately, as I was hoping these latest hacks would fix the
read/write locking, it looks like I'll have to wait for the remaining
20% of the fix, since I still see innd blocking during the time the
light on the drive with history is lit.
I did notice earlier with 4.0-STABLE that I had not enabled softupdates
on the /news disk (with the history files), so I enabled it and tried
looking at numbers again. There was no improvement -- if anything, it
almost seemed like the time that INN was spending in history-related
activity (writing or lookups) increased somewhat.
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.
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
/news/log/news.notice. `expire' also causes things to grind to a
crawl -- even when `nice'd, the incoming article rate drops to about
one third of normal.
I won't say there's no improvement, since it's hard to tell with the
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.
More importantly, I haven't seen any problems with it yet, and I'm
eagerly looking forward to the best 20% of the fix to come...
(I haven't tried tweaking any sysctl knobs to see if they make any
difference, this is pretty much a standard installation with the
same old INN k0deZ as on the other test machines)
barry bouwsma, newsmangler & netscum
--
*** This was posted with the express permission of ***
******************************************************
** HIS HIGHNESS KAAZMANN LORD AND MASTER OF USENET **
******************************************************
********* We are simple servants of his will *********
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.1000405025135.7687C-100000>