Date: Tue, 25 Jan 2000 01:41:36 +0100 (CET) From: K0dewanker <kvindeservice@Fluffy.gets.an.analprobe.dk> To: freebsd-current@freebsd.org Subject: big files, blocking in inode, kern.update, and so on... Message-ID: <Pine.BSF.3.96.1000125005653.52578B-100000@fLuFFy.iNt.tElE.dK>
next in thread | raw e-mail | index | archive | help
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?Pine.BSF.3.96.1000125005653.52578B-100000>