Date: Sun, 06 Feb 2005 09:56:13 -0700 From: Scott Long <scottl@freebsd.org> To: Chris <chrcoluk@gmail.com> Cc: freebsd-stable@freebsd.org Subject: Re: 5.x concerns Message-ID: <42064C2D.6030401@freebsd.org> In-Reply-To: <3aaaa3a05020607013bff630e@mail.gmail.com> References: <3aaaa3a05020607013bff630e@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Chris wrote: > Hi > > I switched over half a dozen or so servers to 5.x since october last > year expecting the same stability and performance I have had from > freebsd 4.x, after running it for 2 or 3 months I have ran into some > problems/concerns, listed below. This is not intended for anything > other then feedback and andswers to my questions I am well aware of > the hard work put into freebsd and will continue to love the os. > > 1 - Speed, performance, All but 2 of the servers are normal Single > processor machines and I think mainstream is still single processor, > whilst there are smp machines and 64bit machines cropping up they are > still a minority, what I have noticed first hand and read on the web > is that 5.3 is sluggish behind 4.10 on single cpu machines, whilst on > 64bit and smp machines it whizzes along. Was it a wise decision to > only concentrate on smp performance as what seems to be the case and > is there going to be single processor improvements to come? > The focus on SMP is an investment in the future. Within a few years, multi-core CPUs (not just Hyperthreading) are going to become the norm, and single CPU systems will eventually become the minority. Of course, that might not help you today when you look at your investment in single CPU systems, and I can understand your frustration. FreeBSD 5.x has mostly been about laying the foundation for the new model and ensuring that it works correctly. We've tried to bring performance up to an acceptable level on UP, but there is obviously still work to be done. Luckily, a number of developers are actively engaged in this work, from making locks cheaper to cutting down on interrupt handling latency. > 2 - stability, about 75% of my servers are fully stable on freebsd > 5.3, on 4.x I have had no stability issues. We have 1 server just > continously locking up, another one that has tcp stack problems (its > to do with the network side of things as locally it responds but goes > offline), and has to be rebooted every few weeks. Are you using plain 5.3-RELEASE, or are you tracking the RELENG_5_3 or RELENG_5 branches? A number of bugs have been fixed since the 5.3 release. It would be quite interesting to find out the nature of your problems. > > 3 - robustness, 5.3 seems to not handle ddos attacks so well, I > remember on a 4.x machine I could easily take a full 100mbit udp flood > and have the server respond albeit maybe with some lag but it stayed > functional, 5.x seems to crumble under a lot less pressure on the same > machine. This could be with pf been loaded on top of ipfw adding > extra overhead I dont know. This probably would add quite a bit of overhead. The ipfw package is not locked, so dealing with that adds even more overhead, unfortunately. > > 4 - compatiblity, I remember using 5.2.1 and pretty much all software > worked well in that and then they did the bind defaulting to base and > libs version jump, why wasnt this done in 5.0 so 3rd party apps could > adjust, now we have a situation where most stuff that worked in 4.x > worked well in 5.1 and 5.2.1 but then broke in 5.3 so effectively 5.3 > was liek a new major version over 5.2.1. 5.3 was the first release that we actively advertised as having API stability. There were a number of library problems compatbility problems that we caught and fixed before 5.3 was released, and that led to the library version bumps. A valid argument could be made that 5.3 should have been called 6.0, though. > > I doubt I will be rolling back my server's as I know things will get > better over time but new server's we build I will expect to be > deploying 4.10 on them. I just feel with the ULE scheduler stuff and > the IO performance issues I have heard about along with the issues I > have come across that 5.3 got rushed towards the end, and instead of > keeping 5.x as CURRENT they wanted 5.3 to be a production release so > disabled some things such as the ULE scheduler to force it to be > stable and its turned out a bit messy. Has anyone else got comments > on my 4 main points? ULE was indeed turned off because of performance and stability problems. It has a lot of potential and I do hope it gets to the point where it can be made the default again, but for now the 4BSD scheduler is a better choice for most people. The problems with ULE would have forced us to disable it for the release regardless if the was -CURRENT or -STABLE. I'm taking a hard look at I/O performance right now while I optimize a number of drivers. There is have been a number of discussion on various mailing lists recently about I/O performance (most notably on the freebsd-performance list), and if you have any data to share, I'd like to see it. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?42064C2D.6030401>