I've just finished compiling and installing a new FreeBSD kernel (7.0-RELEASE) on a Pentium 166Mhz. It took about 12 hours to complete. Actually, it took about 1 hour, but all the modules took 11 hours.

By default, the kernel build will compile _all_ modules. Even if, for instance, you disable FireWire in the kernel, it will still build the FireWire modules! Now, I didn't realise this was going to happen, and I found out that you can specify what modules you want compiled to over ride this behavior. So the question became, what modules out of the available modules do I need? And the corollary of this is: What is the list of available modules for my kernel version?

I couldn't find an answer to this anywhere on the web. All the resources I found were related to writing a kernel module, not choosing from existing modules. Anyway, I dived into the directory of the kernel source, and it's actually all there.

/usr/src/sys/arch/i386/modules

And each directory is a module. There's a lot of sub files that show up in the compilation of the kernel, but that's basically all the modules. So save yourself about 90% compilation time, and use the /etc/make.conf to over ride the modules that get built!

The actual procedure for compiling the kernel is in the FreeBSD Handbook.

This configuration DOES work. I'm using it in my testing environment right now just to make sure the caching doesn't interfere with my production software, but the application itself is fine.

One note though, the control panel that is distributed with eAccelerator will not work with this configuration. The reason is that the basic authentication via the PHP headers that the file uses does not work when PHP is a CGI. It only works when PHP is an Apache module.

A quick hack I made is to use a simple session key instead. This is a straight dump from vi with the line numbers on, from the eAccelerator 0.9.5.2 control.php file:


31 /* {{{ auth */

32 /*if (!isset($_SERVER['PHP_AUTH_USER']) || !isset($_SERVER['PHP_AUTH_USER']) ||

33 $_SERVER['PHP_AUTH_USER'] != $user || $_SERVER['PHP_AUTH_PW'] != $pw) {

34 header('WWW-Authenticate: Basic realm="eAccelerator control panel"');

35 header('HTTP/1.0 401 Unauthorized');

36 exit;

37 }*/

38 /* }}} */

39 if( $_SESSION['xxx']!=$mykey ) {

40 if( ($_POST['user']!=$user) && ($_POST['pass']!=$pw) ) {

41 ?>

42 <form name="basicauth" method="post">

43 <input name="user" type="text">



44 <input name="pass" type="text">



45 <input type="submit">

46 </form>

47 48 exit;

49 } else {

50 session_start();

51 $_SESSION['xxx'] = $mykey;

52 }

53 }


You can see I've commented out the original auth. I haven't even bothered labeling the form fields here. The form will automatically submit back to the page it is on. The session key is protected by you setting the key value and the key value. It works quite well for a 5 minute hack.

I've been investigating FreeBSD as an alternative to Debian on some of my systems. I used it a couple of years ago, in version 5, and it was nice. Performance wasn't an issue back then though, it was more of a case of getting applications installed an configured. Because I was happy with Debian and had no complaints, I really didn't have any reason to shift. With Splunk eating my low end hardware though, I thought this would be a good oppurtunity.

There's many forum threads out there dealing with the issue of Linux vs. FreeBSD, so I'm not going to cover the issues here. In these open source forums though, it's cautionable to make sure you have the latest information. Many forum threads on this issue cite the bad SMP support / performance in FreeBSD when compared with Linux. Well that's just hogwash since version 7. I found a really nice web article dealing with a comparison of BSD variants, and one of the issues it covers is the SMP performance of FreeBSD 7. I thought it would make a good graph to post :)

As you can see though, FreeBSD 7 certainly scales with SMP quite well.

Ok since I have started getting used to Splunk and finding how much easier it is than cat /var/log/mail.log | grep 'user@domain', I added the rest of my logging to it. This amounts to about 80M / day. Firstly, because I use SSHFS a lot, Splunk killed the CPU when it was indexing - the CPU was a K6-2 333. I overclocked it to 343, which ultimately did not help ;)

I think the CPU might have been "ok" bu t I swapped it for a K6-3 400 anyway, which I've had no problems with. The bigger problem was the fact that during indexing, Splunk ate my RAM. 384M. I woke up to a hard disk thrashing at 60 pages / sec. The box didn't crash though, Linux did it's due diligence and started purging processes ;)

Anyway I've now increased the memory to 586 (512 + 64), and Splunk is fine. No problems at all. Load seems to top out at about 3 which is nice. No swapping. I will mention that the same box is also running a MySQL server, LDAP and DNS Masq. Those services don't eat CPU or much RAM because they are not normally used, but it is nice to be able to access them rather than to find they've been killed to make room for Splunk.

Conclusion: Splunk WILL run with less than the 1G "minimum" RAM that Splunk say in the system requirements documentation...but if you go below 512M, you're gonna swap. And 1.4Ghz minimum CPU well...f3ar my K6-3 ;)

Because my directory server is running on quite old hardware (K6-2, 256M RAM), and it is faily loaded already, I wondered if changing the MTA might help. I use Debian, and I've never changed the MTA on it, so it currently has Exim.

The system doesn't process much mail, mainly just local mail and spam, so I'm not conerned about scalability. I did some digging on Google, and found a great comparison between Unix MTA's. It might for an enlightening read. I also found a forum thread talking about the scalablity of Exim, and I have to say that guy has a sweet server setup, with his MTA's PXE booting and installing automagically...it's just like Active Directory! :)

Anyway back to it. I couldn't find any conclusive measurements, or even vague measurements, of the resource usage between the two programs. I happen to have another server that doesn't process any mail and runs Postfix, so I thought I'd just take a peek at the memory usage of the two. It looks like Postfix runs separate programs for the queue management and the program itself, and it weighs in at about 2.5MB of memory. Exim has a single process and weighs in at about 450k.

Quite a difference. There wasn't much point in looking at the CPU load - it's 0 because neither of them are processing any mail ;)

I think I'll stick with Exim on my directory server though. Lower memory footprint = better at the moment.