At 07:14 AM 12/24/2007, Scott Long wrote: >Brett, > >There could be several problems here: > >1. WITNESS, INVARIANTS, malloc debugging. Are any of these turned on for you? > I don't recall if malloc debugging got turned off yet for the >7.0 snapshots.
I nuked debugging when I recompiled the kernel with SCHED_ULE. >2. Disk subsystem. What kind of disk controller are you using? Not all >drivers work well in FreeBSD. Are linux and freebsd using identical >hardware? They were. The drives are SATA. >3. Directory hashing. If you're using squid, you __must__ tune the DIRHASH, >otherwise you'll spend a lot of time doing pathname lookups. What filesystem >is linux using? Whatever comes standard with Ubuntu. As for directory hashing: Squid doesn't use more than 256 entries in each one, so that's what I normally set. I also normally do a newfs with parameters that favor the distribution of object sizes found in Web caches. (We did this on both Linux and FreeBSD.) >Would you mind if I logged into your test system and looked around to >help diagnose the problem? The system isn't online now, because it's been a week since the tests and I also wanted to try the 6.3 beta and a few hardware changes. My guess, based on what I saw, is that UFS2 doesn't take as much advantage of SMP as Linux's file system does and threads are blocking on file I/O. (Networking does not seem to be the botteneck, though I have heard that the IP stack in 7-CURRENT needs optimization and that this had been proposed as a sponsored project.) --Brett P.S. -- If the chip manufacturers were not making it so that one needs to go to SMP to get more processing power, I wouldn't be doing SMP. I'd rather use FreeBSD 4.11 on a single core "gaming" CPU, as I did a few years ago when I needed a very fast server. But this isn't a viable option nowadays.... _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
