Date: Mon, 13 Nov 1995 13:49:08 -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: <199511131949.NAA27664@brasil.moneng.mei.com> In-Reply-To: <199511131815.LAA16915@phaeton.artisoft.com> from "Terry Lambert" at Nov 13, 95 11:15:05 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > This noted as well. I am frustrated that I cannot seem to hit more than a > > PEAK of 4 arts/sec without MMAP, or around 5.5-6 with MMAP. My pet Solaris > > news server, with PrestoServe and 128MB RAM, and only 4 disks, can peak out > > at around 15. I do know that with only 48MB of RAM, news.sol.net takes more > > of a hit on history lookups (expected), but with the I/O load spread over a > > dozen disks, I would expect that would compensate somewhat... > > PrestoServe does striping. Striping is a win for concurrency of access; > probably not nearly the win kernel reentrancy would be in effective > concurrency, but still a major win. 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 :-/ 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). > I would like to see striping, volume spanning, and other technologies > integrated by way of devfs. This requires a cleanup/reworking of the > way that volumes and media perfection, etc. are handled in BSD in general, > and the whole idea of logical drives in specific. I would like to see this as well :-) > > Test code that breaks, problematic - at least as far as MMAP goes. MMAP > > appears to work fine at first glance, but the panic rate of the system goes > > from once every few weeks to once every two or three days. I have no idea > > what tickles it. > > Any way to get a traceback? Any particular panic message? I hadn't tried recently (post-2.0.5). I am more than willing to try things iff there is any interest by qualified parties (that would most likely be the VM gods) to try to analyze the dumps to determine what happened. > Can you force the panic to happen? Yeah, I can run the system with MMAP. :-) (well, as noted, I haven't tried under the latest SNAP to cause this behaviour, but I AM willing to put my feet in those fires again if it will be USEFUL). > > I can probably get you some numbers in terms of file creation/removal rates > > on both Solaris x86 and FreeBSD 2.1R (well, SNAP). I don't know what they > > will look like so it would be a doubly interesting test for me to perform. > > Unless the Solaris volumes are mounted async, I expect them to be on > the same order as FreeBSD numbers if taken from similar drives. 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. ... 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?199511131949.NAA27664>