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

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!

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: 9.2 Why Build a Custom Kernel?

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 person to miss the last time of my first section: "I have tried not to duplicate the data in the tuning(7) man page, which already contains a wealth of good information on the basics of system performance tuning." :-) I'll happily go over and fix any errors I made. It's a living document.

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

[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 are going to go -- at least assuming that nobody comes up with a faster method of locking on SMP platforms.