From owner-freebsd-current Mon Nov 13 13:23:03 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA29669 for current-outgoing; Mon, 13 Nov 1995 13:23:03 -0800 Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.20.4]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA29658 for ; Mon, 13 Nov 1995 13:22:57 -0800 Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id PAA27837; Mon, 13 Nov 1995 15:21:35 -0600 From: Joe Greco Message-Id: <199511132121.PAA27837@brasil.moneng.mei.com> Subject: Re: ISP state their FreeBSD concerns To: terry@lambert.org (Terry Lambert) Date: Mon, 13 Nov 1995 15:21:34 -0600 (CST) Cc: dyson@freefall.freebsd.org, current@FreeBSD.org In-Reply-To: <199511132047.NAA17982@phaeton.artisoft.com> from "Terry Lambert" at Nov 13, 95 01:47:06 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@FreeBSD.org Precedence: bulk > > PrestoServe does not do striping. PrestoServe does writeback caching. This > > helps by a large margin on things like metadata updates (because you can > > write to cache and have a change queued to be written to the drive, and make > > several more changes before the write actually gets scheduled to hit the > > physical disk). > > > > On-Line Disk Suite does striping, concatenation, mirroring, and logging > > filesystems. It and PrestoServe are only somewhat compatible :-/ > > Damn. I always get those products confused. 8-(. :-) > The use of server caching is discouraged without some type of log forward > mechanism that can't be implemented without additonal hardware. > > NFS server caching sucks, almost as bad as NFS client caching. PrestoServe is a battery-backed RAM cache. This is the way you wanna do NFS server caching, if you do it at all. ;-) Of course, while it works *best* for NFS server caching, it is also a good general purpose writeback cache, which is why it is a win on a news server. > > The other factor is that for effective concurrency, you need multiple > > processes. INN is a monolithic news processing engine, and you cannot get > > the kind of concurrency needed to increase article processing performance > > even on a multi-CPU Solaris box. (well, this is an oversimplification of > > the problem, but the point is that it is a single process which needs to be > > able to do many hundreds of disk I/Os per second). > > Or async I/O. Or auto-thread generation for blocking oprations. Etc. > > This is a design problem with the news server, and we aren't going to > fix it here. 8-(. Realize that. But that's not to say that it's not a good reason to improve what is really suprisingly abysmal performance in the filesystem. :-( > > Taken from THE SAME drive, > > > > Slowaris 5.4 - SS10/30 - 64MB RAM (SCSI II, reasonable drive) > > > > 10000 files in 332 seconds - first run > > 10000 files in 20 !!! seconds - second run > > > > FreeBSD 2.0.5R - ASUS SP3G AMD 486DX2/66 + NCR810 - 8MB (SCSI II, reasonable > > drive) > > > > 10000 files in 620 seconds - first run :-( :-( > > 10000 files in 310 seconds - second run :-( :-( :-( !! > > > > That does not appear to be "the same order as" :-( > > > > I haven't yet tried Solaris x86 - we just got gcc installed on our "test > > box" today. > > Is the Sun running with PrestoServe or OLDS installed? This would be > an unfair comparison... Of course it would :-) The PrestoServe numbers were also posted in my original benchmark posting, but this is a pure Solaris system with no additional garbage. The systems quoted above are functionally equivalent and I would expect to perform similarly - except that the ASUS had much less memory. This could be partly a caching issue of some sort, in which case I would notice a difference if I put another 8MB RAM in, but I have yet to try that. And it does not explain the difference between 332 and 620 seconds (in my mind). ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847