Date: Thu, 23 Mar 2000 01:17:06 +0100 (CET) From: FREENIX IS OVERRATED <pedophile@INT.TELE.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.1000323001655.85607G-100000@fLuFFy.iNt.tElE.dK> In-Reply-To: <fa.kiqr0qv.1enaji3@ifi.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2395 Sep 1993, Matthew Dillon wrote:
> It is perfectly ok for dirty blocks to remain in the buffer cache. In
> fact, it's *optimal* to leave them in the buffer cache as long as the
> buffer cache does not get saturated with them. The buffer cache is
> perfectly capable of clustering delayed writes. Also, the filesystem
> syncer comes along every 30 seconds or so anyway and flushes everything
> out.
>
> What the write-behind code tries to do is to prevent the buffer cache
> from being saturated with dirty buffers and to smooth out disk write
> I/O. It makes the assumption that write-behind data is not typically
> accessed by the program immediately after being written -- an assumption
> that winds up being incorrect in the DBM case you tested and resulting
> in stalls due to the buffer / VM pages being locked during the write I/O.
> The stalls are *not* due to the I/O itself but instead are due to side
> effects of the I/O being in-progress.
And that sounds a heck of a lot like what those of us who have been
running INN news swervers with 1,1GB size text history files on 2.whazzit
(now dead, may it rest in pieces widely-scattered) and later have seen.
You should have forgotten that a couple months or so ago, I wrote to
one of these lists to ask why I was getting only about 50-70%
availability as my 1.5+MD5-based-dbz innd was stuck in ufslck2 during
these every-30-seconds syncs. The .hash and .index files from this,
which are comparable to the dbm (dbz) files being typically 125MB and
85MB or so, this under 3.4-STABLE.
Well, I've meant to get around to trying 4.0 on it, and Real Soon Now
I will, but I wanted to relate my experiences in turning traitor, a
heretic who has left the fold, deserving to be ridden out of town on
a rail and stuff, which sounds like a lot of fun. I tried NetBSD.
NetBSD (at least the development now 1.4V version) has trickle
syncing, which seems to work quite well when having to cope with
these rather large database files, keeping a full 14 days of message
IDs from a full news feed.
Without really tuning anything, after a bit of time, the time needed
to do history lookups drops to microseconds, and as long as a `sync'
isn't needed, innd doesn't get stuck. Theoretically, a sync, where
you are in fact seeking rather wildly over the disk to update these
files, happens once a day at expiry. Depending on the speed of the
drive (and I haven't optimized this at all, using a single drive for
OS, logs, history, and part of spool, with a second drive for the rest
of the spool, far from an ideal setup), this seems to mean only a
few minutes of downtime. Actually building the new .index and .hash
files goes quite a bit faster, like by a factor of 3 to 4, so clearly
the update of these files during the `sync' could stand improved sorting.
I wouldn't complain a bit if you were to steal mercilessly from the
NetBSD k0deZ to incorporate trickle sync (if something comparable is
not already in place) since that seems to make a world of difference
for those of us using long-outdated INN code and who want to have
bigger history file sizes than our shriveling Freenix members.
(What kills me now is that I'm using a single drive to hold the news
spool apart from a small overflow, so while time spent accessing this
history database is way down, the time actually spent hopping around
the disk to write (and read, for our sluggish peers) articles has
skyrocketed. The box I'll try 4.0 on has a separate disk pack that
is far faster under NetBSD. Test boxen, eh?)
There. I've confessed. It feels really good. Now have at me.
Naturally, since I haven't followed this discussion closely, you may
be talking about something completely different, but I did want to
mention generally improved (yet not totally perfect) performance
with huge INN database files and NetBSD's trickle syncing. Now,
go out and steal some k0deZ, okay?
barry bouwsma, tele danMerika internet
--
*** 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-fs" 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.1000323001655.85607G-100000>