Two papers On Performance Tuning FreeBSD

avleenvig writes "Finally I have completed my paper on tuning the FreeBSD system for various common tasks, to compliment the paper on compiling and tuning the FreeBSD kernel. These papers were written against FreeBSD 4.x systems but should be equally applicable to 5.x systems on almost all counts. Compiling and tuning the FreeBSD kernel: http://silverwraith.com/papers/freebsd-kernel.php Performance tuning FreeBSD for different applications: http://silverwraith.com/papers/freebsd-tuning.php. You will find within, details on tuning your network, disks, sysctls and kernel for maximum performance under various conditions. "

Comments

Re:For beginners in performance tunning good enoug

[avleenvig]

Thanks for the good word :-) I tried hard to cover things not mentioned in tuning(7). That page alreasdy has a lot of good stuff in it that I couldn't really improve. I felt there was something missing though and when I first started performance tuning I found that the data I've written about isn't in one single location. Of course, I'll keep adding to it as I learn more. Hopefully in the next week I'll have a paper up on what you can do to your server to keep it up during DDoS attacks (or if you're slashdotted ;)

Doesn't really help performance

[ebcdic]

The handbook mentions three reasons to compile your own kernel. None of them really makes much difference to performance:

Faster booting: yes, but that's not really performance in the sense being considered.

Saving memory: yes, but it'll only be a megabyte or two. Insignificant on most machines where performance is important.

Hardware support: yes, but that's not performance improvement.

So build your own kernel - it's educational if nothing else - but don't expect anything to run faster as a result. The only reason I build my own kernel is to apply some useful patches: one to spin down ATA disks when they're idle, and one to enable power-saving in the VIA chipset when the machine is idle (makes it *much* cooler).

Well...

[chrysalis]

Both articles give nice ideas, but it may not be a good idea to blindly follow their advices.

For instance, polling doesn't always improve things. Past the theory, I tried to enable device polling on a web server running FreeBSD 4.9-STABLE and the performance significantly _decreased_.

Also one of those papers suggests playing with extra GCC optimization flags. Well. First, don't expect your system to get significant speed improvements except for some very specific applications (usually not servers, rather intensive maths work).

Next, FreeBSD is not Gentoo Linux.
Gentoo has tons of users heavily testing all possible GCC optimization and discovering breakages. Those breakages are solved by adding extra patches, by backporting patches from CVS trees or by filtering annoying gcc flags for some piece of software. The whole thing works and it is even reliable because Gentoo Linux was designed that way and people use it that way.

On the other hand, almost no FreeBSD user use special flags. Even nothing but "-O" is explicitely recommended. There is no Gentoo-like workarounds for specific optimization flags. Nothing is really tested with extreme compiler optimization flags. So if you start playing with this, you may hit strange bugs and not a lot of people would have encoutered the same bug. So you're on your own. Your system may be unstable while your actual gain of performance will be near zero (really in a real world, bottlenecks are often disk/io, ram and network latency).