OSNews

So after my article hit Slashdot, Sean Brown (who initially replied to my post to the OpenBSD/sparc mailing list) posted a response on Slashdot about the MySQL Manual having a known issue regarding OpenBSD 2.8.

I checked the MySQL Manual and I found the entry to he was referring to. The entry, listed as an OpenBSD 2.8 issue, seems to cover two distinct problems. The first issue listed is a threading bug where the symptoms manifest as (quoting from the entry) "slow response, high load, high CPU usage, and crashes". That wasn't what I was seeing, and it appears to be specific to OpenBSD 2.8.

The second paragraph in that entry seems to describe a problem which matchs exactly the issue I was having, and from the comments and my experiences it seems to affect OpenBSD of a variety of versions for a variety of platforms, not just 2.8

The entry recommend using --open-files-limit=2048 when invoking the MySQL daemon. It turns out it was a file descriptor issue, but I was changing file descriptors at the wrong place (that being sysctl). The user comments in the entry seemed to confirm this, and sure enough, using that flag sql-bench successfully ran.

I submitted a recommendation to the MySQL Manual page to list them as two separate issues.

Finally, Some Benchmarks!

With my compiled version of 4.0.17 running swimmingly, I am now able to share some benchmarks. Just to recap, I'm using the version of MySQL 4.0.17 compiled from source tarball off of MySQL.com's site. I used no compiler optimizations (although since this is a 64-bit operating system, the V9 instruction set [-mcpu=v9] is automatically used).

I ran the sql-bench benchmarks, and compared the results to results from other operating systems running on the same hardware (my Sun Ultra 5, as detailed in my first article).

The Solaris, Linux, and FreeBSD results were compiled from earlier tests from the same 4.0.17 source. They all ran as 64-bit binaries on 64-bit kernels with the exception of the Linux binary, which ran 32-bit on a 64-bit kernel (2.4.24).

For alter-table, ATIS, bit-tables, connect, and wisconsin, OpenBSD 3.4 performed favorably compared to Solaris 9, Linux 2.4.24 and FreeBSD 5.2.1.

However with the insert test, OpenBSD did terrible, performing worse than FreeBSD 5.2.1 which itself had a pretty awful showing.

The insert test took about three times longer to complete than on Linux or Solaris, and it was even worse than FreeBSD 5.1 which took 18,730 seconds (roughly 5 hours, 12 minutes) to complete the operation, where OpenBSD 3.4 took 24,226 seconds (about 6 hours, 43 minutes).

And now, OpenBSD 3.5

Since OpenBSD 3.5 is now out, I decided to give it a spin as well. Upgrading was a breeze. I made an OpenBSD 3.5 boot CD and booted up the installer. I chose the upgrade option, used the current networking configuration, and told it where to find a local FTP server with the 3.5 tgz files.

(I)nstall, (U)pgrade or (S)hell? u

Welcome to the OpenBSD/sparc64 3.5 upgrade program.

This program will help you upgrade OpenBSD in a simple and rational way. At
any prompt except password prompts you can run a shell command by typing
'!foo', or escape to a shell by typing '!'. Default answers are shown in []'s
and are selected by pressing RETURN. At any time you can exit this program by
pressing Control-C and then RETURN, but quitting during an upgrade can leave
your system in an inconsistent state.

To see how MySQL faired on OpenBSD 3.5, I ran the sql-bench against the newly upgraded system.

The results were roughly the same with OpenBSD 3.5 as it was for OpenBSD 3.4. OpenBSD 3.5 seemed to have a slight performance gain over OpenBSD 3.4 for these tests, although for the insert and select tests, OpenBSD 3.5 still gets blown out of the water by Solaris and Linux.

1. "OpenBSD for SPARC64, Page 1/3"
2. "OpenBSD for SPARC64, Page 2/3"
3. "OpenBSD for SPARC64, Page 3/3"