blog@insidesystems.net

I’m hoping that somebody will look at this and say “hey, dummy, you did this all wrong.” I’m hoping that, because the results are shocking.

There have been a buzz about FreeBSD’s SMP performance compared to Linux’s, particularly a particular 8-core SMP test, using FreeBSD 7.0, sysbench, and mysql. A number of people mentioned that there were known problems with this test and PostgreSQL, so I decided to see how bad the problems were.

We’ve been buying a lot of new machines today, and almost all of them come with SAS drives. We bought 10K SAS drives for obviously performance-neutral applications, and 15K SAS drives for performance-critical applications, but what exactly did we get for an extra $200/drive?

I decided to do some wildly unscientific tests, using two HP DL360s, one with mirrored 10K RPM drives, the other with mirrored 15K RPM drives, both running FreeBSD 6.2/AMD64. Both machines are equipped with P400i drive controllers.

A client had an interesting problem. They had a critical PostgreSQL database, and they accidentally ran an overly broad delete on a table.

And their newest backup was two weeks old.

Could we help? Of course we could help.

I was helping move a legacy PHP app to a new server, and found it needed a PECL extension (dbx).

After installing PEAR, I got the following error:

[root@machine php]# pecl install something

Fatal error: Call to undefined function preg_match() in /usr/local/share/pear/PEAR/Frontend/CLI.php on line 70

It’s not often that somebody points out FreeBSD functionality that I wasn’t already aware of, but that happened today.

We were having a problem with clamav 0.90. It would slow down, stop responding, and die, somewhere in the threading code.

Craig Green, of Sentex.net, wrote us to say that he had a similar problem with a devel version of clamav on FreeBSD, and his fix was quite unexpected.

If you’ve run Apache in a FreeBSD jail, you’ve probably seen the following error messages in your error log:

     (61)Connection refused: connect to listener on 0.0.0.0:80
     (61)Connection refused: connect to listener on 0.0.0.0:80

It turns out that if you specify the Listen directive in one of the following ways:

     Listen 80
     Listen *:80
     Listen 0.0.0.0:80

it complains about connecting to the listener as previously mentioned. To make these errors disappear from the logs, all you have to do is specify the IP address of the jail like so:

     Listen jail.ip.address.here:80

and it goes away. No more error messages filling the logs.