Date: Mon, 13 Nov 1995 15:21:34 -0600 (CST) From: Joe Greco <jgreco@brasil.moneng.mei.com> To: terry@lambert.org (Terry Lambert) Cc: dyson@freefall.freebsd.org, current@FreeBSD.org Subject: Re: ISP state their FreeBSD concerns Message-ID: <199511132121.PAA27837@brasil.moneng.mei.com> In-Reply-To: <199511132047.NAA17982@phaeton.artisoft.com> from "Terry Lambert" at Nov 13, 95 01:47:06 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511132121.PAA27837>