Date: Mon, 24 Jan 2000 18:17:56 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: K0dewanker <kvindeservice@Fluffy.gets.an.analprobe.dk> Cc: freebsd-current@FreeBSD.ORG Subject: Re: big files, blocking in inode, kern.update, and so on... Message-ID: <200001250217.SAA94691@apollo.backplane.com> References: <Pine.BSF.3.96.1000125005653.52578B-100000@fLuFFy.iNt.tElE.dK>
next in thread | previous in thread | raw e-mail | index | archive | help
Hmm. It sounds like the system is doing a huge amount of seeking to
flush the dirty buffers. Your history file may be badly fragmented on
the disk. The first thing I would do is take the system down and copy
the history file to reorder all of its block. i.e. 'cp fubar fubar.bak'
then 'mv fubar.bak fubar'. Assuming you have the space.
You may be able to force the system to write more smoothly by reducing
the vfs.hidirtybuffers water mark.
There are other possible solutions if you can track down the piece of
code causing the most trouble. I believe that newer versions of INN
use shared R+W mmap()'s which can cause fragmented dirty pages. The
syncer will push these pages out every 30 seconds or so. If this is what
is causing the problem you can solve it under -CURRENT by adding MAP_NOSYNC
to the mmap() call in question (though I don't know which one it is, I
haven't used INN recently).
-Matt
Matthew Dillon
<dillon@backplane.com>
:Howdy, me again...
:
:I wrote to some freebsd list some months/years back asking about
:this, but now it's time to revisit things.
:
:We have an old t^Hrusty 2.2-RELENG box from '97 that's been running
:like a champ, kinda, after hacking around the problem. But it's
:time to retire that underpowered box that sees occasional mysterious
:kernel panics and move on to more reliable hardware.
:
:Our machine is running a very hacked version of INN 1.5.1 to which I've
:added the MD5 history routines, and remembering news articles for a full
:14 days. This means that we see history file sizes on the order of
:-rw-rw-r-- 1 news news 1013138182 Jan 25 01:03 history
:-rw-rw-r-- 1 news news 120 Jan 25 01:03 history.dir
:-rw-rw-r-- 1 news news 167184942 Jan 25 00:32 history.hash
:-rw-rw-r-- 1 news news 111456628 Jan 25 00:31 history.index
:
:I've now taken this code and installed it on two machines, one a
:Solaris box, and the other a FreeBSD-STABLE machine from a couple
:weeks ago.
:
:First was the Slowaris box, it has its problems but still never
:becomes unresponsive for more than a second or so when giving a
:`ctlinnd' command.
:
:However, as I observed with -current many months ago, the FreeBSD
:box, every 30 seconds, will totally freeze up for the ctlinnd
:command for the duration of time that the history disk light is
:lit and innd is found in `inode' state, which can be 25 seconds,
:although has been only slighter better than that recently.
:
:The history text file is appended to, while the hash and index
:files are essentially randomly updated at a rate of 10+ articles
:per second, so much of the entire file needs to be updated.
:
:Our 2.2 machine hacked around this problem with the non-solution
:of increasing the time between `sync's to an hour, so the machine
:becomes unresponsive for news once an hour for a minute or so,
:much better than a 50% duty cycle.
:
:Now, the `kern.update' sysctl parameter is long gone, and I don't
:see any suitable replacement to try and tweak this, with or without
:softupdates. (I'm not using them yet.)
:
:But my big question is, how does Solaris do it? to be able to
:update these large database files without causing innd to have to
:pause for a significant amount of time? And...
:
:Why can't FreeBSD match the performance of Solaris here? What can
:I do (besides submit patches, of course)? Where did kern.update
:disappear and is there any chance of a replacement?
:
:
:I have a couple more tricks up my sleeve, but I don't think they
:will help as much as we need, these drives aren't what you would
:call slow so a faster drive won't really improve things to the
:point where I'd be satisfied.
:
:
:thanks for any responses...
:barry bouwsma, tele danmark internet
:replies should be directed to the reply-to header address
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?200001250217.SAA94691>