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. "

For beginners in performance tunning good enough

[sumirati]

Both articles are well written and quite informative.

But if you ever had analysed *nix systems for performance bottle necks this could only help for some little problems.

If he had read the tuning(7) man page, there would be more information for other parts of the system.

But he had done that what I didn't: put up a website with informations for anybody. So overall: Great Work!

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 slash

compile your own kernel

[a.koepke]

This has gotta be one the easiest ways to boost the performance of your system.

The best place to look for reasons as to why this helps out so much is the FreeBSD Handbook [freebsd.org]: 9.2 Why Build a Custom Kernel? [freebsd.org]

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

Missing: SMP

[cperciva]

Pre-5.2 RELEASEs ship with uniprocessor kernels. If you want SMP support, you have to recompile.

5.2, and future RELEASEs, will ship with SMP kernels. Due to the added overhead of kernel locking, this cuts kernel performance by about 20%. If you've got a uniprocessor machine, and you're doing kernel-intensive work, youll probably want to recompile.

Re:Missing: SMP

[nutznboltz]

If you've got a uniprocessor machine, and you're doing kernel-intensive work, youll probably want to recompile.

That's not a problem for me since I never use GENERIC kernels for any length of time but this clearly pushes FreeBSD away from the desktop even further.

How hard would it be to offer both an SMP and non-SMP GENERIC kernel and just mv the one you want into place?

Re:Missing: SMP

[cperciva]

Well, most of what people do on desktops isn't kernel-intensive. But you're right; this is a consideration, and I'll be raising the issue after 5.2 is released.

There's two issues here; first, sysinstall needs to be updated to ask the user which kernel is desired -- and sysinstall is a minefield which most people want to avoid at all costs. Second, shipping two kernels eats up disk space, and the ISO is getting rather crowded already.

But yes, I imagine that shipping two kernels is the direction things ar

More like this!

[Leroy_Brown242]

I wish there were more usefull step by step how-to stuff on the web like this. Too often I look for how to do something and I have to figure it out in bits an pieces.

It difficult for the people in the land between complete noob, and guru. It's like I'm an advanced user that has to admin his own box. ]:3}>

Re:More like this!

[burns210]

first bsd is dying, next they will start calling you an insensitive clod and making natalie portman jokes about your posts.

Re:More like this!

[JamesTRexx]

Well, there are some FreeBSD diary pages out there, and I've been thinking about documenting my next install of FreeBSD with Qmail, DJBdns, Proftp, Samba, Zope, and anything else I use for my network.
Not only as a reference for myself (I should have done it with my current install), but hopefully to give a hand to other (sort of) newbies like me who want to run FreeBSD at home or at work.

Re:More like this!

[Dick Faze]

That would be useful: BsD+Qmail is always a day for me since I do it once a year & am too lazy to write all that funky shit down!

Here Be Dragons

[DES]

Some of the procedures described in these so-called "papers" (they are really too short to merit the name) are in direct contravention of the FreeBSD Project's recommended and supported procedures.

The recommended way to build a kernel is with the 'make buildkernel' command, after a successful 'make buildworld'.

Optimization levels higher than plain -O (such as the -O2 and -O3 levels recommended by the article) are known to trigger bugs in some of the inline assembler code in the FreeBSD kernel. In previous FreeBSD versions (that shipped with older gcc versions), they were also known to trigger compiler bugs.

The TOP_TABLE_SIZE option is irrelevant to system performance. Likewise, the NFS_NOSERVER option, although it reduces the size of the kernel, does not affect performance. Conversely, none of the truly important kernel options are explained or even mentioned.

The author mentions kern.ipc.maxsockets and kern.ipc.nmbclusters, but fails to mention kern.ipc.nmbufs which must be tuned to match kern.ipc.nmbclusters (the rule of thumb is one cluster for every other mbuf). Also, the suggested values (2048) are very low - lower than the default (which is computed at boot time as a function of physical memory size) and much lower than what a busy network server will need.

Admins who are truly concerned with the performance of their FreeBSD systems are advised to read the tuning(7) manual page, as well as some of the excellent FreeBSD books available from e.g. O'Reilly.

Re:Here Be Dragons

[avleenvig]

Just a few points to note: kern.ipc.nmbufs is by default, 4 times kern.ipc.nmbclusters. I should have made note of this, but once the later is tuned most peopel don't need to tune the former. Reducing the size of your kernel *does* improve performance. You should make it clear that if your server does not have a lot of physical memory, things like the values determined with maxusers=0, will be very low. You're the second person to mention tuning(7), which means I can only assume you're also the second pe

Re:Here Be Dragons

[DES]

Do you have any evidence at all to back up your claim that reducing the size of the kernel will increase system performance? Have you run benchmarks which clearly demonstrate that a kernel compiled with the NFS_NOSERVER option performs better than a kernel built from the same sources but without that option?

I'm pretty sure that you haven't, and I'm pretty sure that if you do, you'll find that there is no appreciable difference.

Re:FreeBSD: why is it better than Linux?

[nutznboltz]

FreeBSD committers are a bunch of *bleep*

Wow! After reading your kind words I just can't wait to try Gentoo. I want to be your friend and run the same code as you since you are so kind and friendly.

performance gains compared to unoptimized system?

[Anonymous Coward]

The papers are great but I'm missing a important aspect of it.

I don't know what kind of performance gains I can expect. It might not be worth the trouble if you gain a few percentage points compared to an unoptimized system. For me if an optimization can make you gain a 10% extra performance (or more!) it begins to be interesting.

Re:performance gains compared to unoptimized syste

[avleenvig]

Well, that depends on on what you're currently doing with your system. For example on one system which is pretty old (a P233), applying the recompiling performance optimizations let X run much faster. I think they'd be less obvious on a faster box. It really depensd on what bottlenext you're currently hitting.

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).

DEVICE_POLLING advice wrong

[muyThaiBxr]

In the DEVICE_POLLING part of the article, he says setting HZ=1000 in the kernel config slows town the clock, but that's wrong... it speeds it up... it ticks ever 1 ms instead of FreeBSD's default ever 10 ms. Last I checked that was speeding up not slowing down.