I still need to boot into a FreeBSD partition on my laptop to do some FreeBSD specific things now and then, which you can't do in a virtual environment.

Setting up FreeBSD to dual boot with Ubuntu (or any other Linux with grub) is simple.

1. Install FreeBSD in a primary partition (slice) and leave some space free for your Ubuntu install during the fdisk part of the installation.
2. Install Linux in remaining space, and install grub boot loader (usually the default)
3. Boot into Ubuntu as it doesn't autodetect FreeBSD partition, and edit /boot/grub/menu.lst (or grub.conf on some other distros) and add the following,

title           FreeBSD
root            (hd0,0,a)
kernel          /boot/loader

http://people.freebsd.org/~kris/scaling/7.0%20Preview.pdf

Slides for those of you curious on why people still use and look forward to FreeBSD 7.0 release in terms of scalability performance.

gambit our main server is now finally stable after several days of unstability after upgrading memory to 2GB. The nature of the problems, strongly makes me suspect that there is a hardware issue in the storage system (possibly chipset of memory/disk controllers). This server was bought on a tight budget a few years back. It is extremely rare for a FreeBSD point release to show random unstability, when it isn't under a heavy load. Unless you're doing something silly like compiling kernel with experimental features and chflags of -O88 -f14m1337.

At the data centre we found out that gmirror is causing kernel trap 9 upon reboot after the server starts having stability issues and random processes core dump. I'm not sure why yet at this stage. On a full disk mirror setup, gmirror module is loaded in /boot/loader.conf. So you will need to go into fixit mode from CD.

For those not familiar with rescuing FreeBSD systems, the first disk has a fixit live file system which you can access from the sysinstall installation menu. This gives you access to a variety of recovery tools and network access. This will allow you to dig around, mount file systems (including external drives) and backup vital data before you try to recover it.

Disabling gmirror leads to a reboot loop, even with correct fstab. If you want to get back the system to basic install again including GENERIC kernel, choose upgrade and map your mount points. If you haven't already, it will backup your /etc to /var/tmp/etc. This got the machine booted up normally again. A quick recompile of the kernel for firewall options and the server is back up again without gmirror.

So far it looks like it's running fine with no issue such as random crashes of processes.

Chapter 11 Configuration and Tuning section of the FreeBSD handbooks provides some good basic advise on tuning FreeBSD.

When running FreeBSD as a host for multiple jails, or as a terminal server the usage is not what you would normally see on a single server or desktop. In both situations, it would be a situation of multiple servers or hundreds of users sharing a single kernel and possibly file sytem. Most of these you can tune at run time (/etc/sysctl.conf) others at boot time (/boot/loader.conf). The following are three, that you probably want to change.

• security.bsd.see_other_uids=0

This one is a good one for multiuser systems, it prevents them from seeing other people's processes. This is also good, for terminal servers also, because users only see their processes.

• kern.ipc.somaxconn

Limits the size of the listen queue for accepting new TCP connections. Got bit by this one, as we added another 2 virtual servers each running multiple services, we had issues connecting to ssh.

Set this as advised to 1024 or 2048 for servers with a lot of network connections.

• kern.maxfiles

Indicates the maximum number of file descriptors on your system. Definitely needs to be increased for a terminal server, as each desktop user would have dozens of applications running and lots of files open.

Similar situation also for servers.

I usually set this at at 25000.

Haven't encountered yet the need to tune other OS parameters, most performance enhancements for me so far has been in userspace. As an example the recent move to Squid front end and removal of Apache rewrites has reduced average cpu use from around 10-25% to neglible levels <3% on our main server. It's very likely we will hit network bandwidth limits before CPU.

This afternoon, I finished replacing Apache httpd with Cherokee on Inigo's main server. Now Squid is handling access to all http services first, with Pound handling the management of the backend servers.

There really wasn't much need for Apache httpd, as we don't use most of it's features and without tuning, it takes up a lot of memory just to do rewrites, http proxy for the backends and logging.

Squid uses much less memory, and is very fast. Kagesenshi is working on tighter integration with Cachefu for the Plone sites. Even without that, you will find that sites like http://foss.org.my are now snappy (1.02 seconds total according to firebug). It's improved the speed of http://mirror.inigo-tech.com also which is a slow external USB drive.

The performance bottleneck now is actually memory. While FreeBSD's virtual memory does an awesome job (we're using 1201MB of swap at time of writing), we are now running 4 separate virtual servers, each running it's own self contained services. Not much more we can optimize now. Long idle processes of course, take several seconds to swap back in. So adding another 1GB of memory (total 2GB) will give quite a bit of breathing space and get rid of that lag.

For those that are curious, all this including http://www.apdip.net which used to sit it's own server is running on RM2.5K worth of hardware.