In my recent article reviewing OpenBSD 3.4, I ran into a few issues. First off, a few days after my OpenBSD 3.4 article went up, OpenBSD (without bothering to consult me) went and released OpenBSD 3.5. I hope no one noticed.
Another issue I ran into was that I unable to get MySQL 4.0.17 or PostgreSQL (7.4.2 or 7.3.2) to run the sql-bench benchmarks successfully. MySQL would die with an apparent file descriptor issue, while PostgreSQL would die from a bus error.
But that was then, and this is now. With OpenBSD 3.5 out, I decided to take a look. I’ve also been able to resolve the issues with MySQL, and I’ve got a batch of benchmarks to share as well as some other goodies.
When I attempted to run my compiled version of MySQL 4.0.17, the tests would eventually fail with errors such as this:
Accessing tables Can't find file: './test/bench_60.frm' (errno: 9) at ./test-create line 137
It looked to others as well as myself that this was a file descriptor issue, but kicking up the file discriptors to as high as 32,000 with sysctl as suggested (and documented in my response to the OpenBSD/sparc mailing list) failed to provide a resolution. The sql-bench benchmarks just wouldn’t run without MySQL dying.
Why Didn’t You Use Ports/Packages!?!?!
Well, there are a couple of reasons why I didn’t use ports/packages for MySQL. The first being that OpenBSD 3.4 does not have a SPARC64 MySQL 4.0.x package or port. There is a 3.x MySQL package and port for SPARC64, but since I’ve used MySQL 4.0.17 for my other evaluations, comparisons with 3.x wouldn’t provide much insight. Also, 4.0 is the current release of MySQL and has many features that 3.x does not.
OpenBSD 3.5 has added a package (which I tested, read on) for MySQL 4.0.18, but of course that wasn’t around when wrote my OpenBSD 3.4 review.
Packages and Ports versus Compiling From Source
Some are of the the opinion that compiling from source is bad, even making the assertion that the OpenBSD FAQ claims not to compile from source unless absolutely necessary (it says no such thing, only recommending that packages are easier). Regardless, I disagree that you shouldn’t compile from source.
While there are cases where packages and ports are easier, I tend (with certain exceptions of course) to prefer compiling from source code whenever possible.
For one, that’s what they’re there for; to compile applications. Packages and ports are meant as a compliment to source compilation and as a convienence, and not a wholesale replacement.
Also, I deal with a number of operating systems on a regular basis, so compiling from source provides a consistency accross a variety of platforms which simplifies my efforts.
Compiling from source gives me a great deal of control over the application such as where it’s installed, what optimizations I may want to use, what features and modules are compiled in, and so forth. While such control can be available in ports (although arguably more difficult to control than it is in source), it’s not available in packages.
There are of course situations where using ports or packages is perhaps the best solutions. For instance, applications that can be very tedious and take an inordinate amount of time to compile. Take GNOME or KDE, for example. They both take a long time to compile (especially on a 333 MHz UltraSPARC IIi), are comprised of a multitude of smaller libraries and components, and on a non-standard operating system is bound to come up with quite a few errors.
For very simple applications, such as the bash or tcsh shell, I also tend to use packages.
Another way that packages and source may help is with non-x86 platforms. In my NetBSD 1.6.2 SPARC64 evaluation, I elaborated the trouble I had with OpenSSL compilations from source. The OpenSSL source distribution didn’t have a compile environment defined for NetBSD 1.6.2 SPARC64. The NetBSD ports section did, however, so I was able to get OpenSSL up and running. I was also able to use the modifications used in ports to get the OpenSSL source distribution compiled and running.
Also, a package or port may not be available for the version of the software (or available period) I’m interested, especially with the more esoteric applications. NetBSD didn’t have OpenSSL 0.9.7, only 0.9.6. OpenBSD 3.4 didn’t have MySQL 4.0.x. in either packages or ports for SPARC64.
However, applications such as Apache, MySQL, PHP, PostgreSQL, Perl, OpenSSH compile in a reasonable amount of time and are relatively easy to install. They’re also components that are often mission and security-critical, so they may need to be updated frequently, and sometimes more quickly than ports or packages can be released.
Sometimes neither package nor port nor compiling from source will provide a solution, such as with NetBSD 1.6.2. The ports MySQL 4.0 just couldn’t successfully compile MySQL 4.0.18, and the NetBSD group did not maintain SPARC64 packages at the time; only SPARC packages. They’ve since added a SPARC64 packages directory, although still no MySQL 4.0.x package. Compiling from source was also fruitless, and to this day I have no MySQL benchmarks for NetBSD SPARC64, which is a shame.
Where Was I Again? Oh Yeah, MySQL on OpenBSD
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.
The entire process took about 15 minutes, and I was up and running with an
OpenBSD 3.5 system.
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.
OpenBSD 3.5 MySQL Package
I ran into some problems, however.
Like many package management systems, OpenBSD packages have the concept of dependencies, where certain packages are required before installing other packages.
Installing the mysql-server required mysql-client. No big deal. But it also required a myriad of other semi-related packages, including p5-DBD-mysql-2.90.03, p5-DBI-1.38, p5-PIRPC-0.2017 and probably a few more.
I’m not sure why they were set as dependencies, as DBI and DBD are Perl modules that are only required when running Perl applications that utilize MySQL. The benchmark suite sql-bench requires them, but for the database server itself to run they are not required.
The frustrating part about this is that there doesn’t appear to be a way to successfully force package installation to ignore dependencies. Using various combinations of the -f keys argument failed install the package.
I tried to install the required packages anyway, but I already had Perl DBI installed, so the package installation failed with the following complaint:
Dependencies for p5-DBI-1.38 resolve to: p5-PlRPC-0.2017 Collision: the following files already exists /usr/local/libdata/perl5/site_perl/sparc64-openbsd/Bundle/DBI.pm /usr/local/libdata/perl5/site_perl/sparc64-openbsd/DBD/ExampleP.pm /usr/local/libdata/perl5/site_perl/sparc64-openbsd/DBD/NullP.pm /usr/local/libdata/perl5/site_perl/sparc64-openbsd/DBD/Proxy.pm /usr/local/libdata/perl5/site_perl/sparc64-openbsd/DBD/Sponge.pm ...
I gave up on the package system and just untarred the tgz file and installed the binaries manually. It was a little tricky, but I got MySQL up and running, and I ran sql-bench against the 4.0.18 package.
The results were somewhat in line with the 4.0.17 version I compiled, although it performed worse in a few of the individual tests.
It looks like they creators of the package are aware of the --open-files-limit fix, as it was incorporated into the mysqld_safe startup script.
Other Odds And Ends
I also had an issue with my compiled PostgreSQL 7.4.2 from source and PostgreSQL 7.3.2 from ports where sql-bench would die from a bus error. However, I didn’t try the package initially so I gave it a try. It also died with the bus error during sql-bench. So no joy there.
I noticed a couple of comments regarding X11, with several incredulous “of course it wouldn’t work!” comments when I tried starting X11 from the serial console. That starting X11 from the serial console didn’t work wasn’t my point; I even stated it wouldn’t work. My concern was that it actually crashed the system, instead of simply exiting with an error. While probably not a DoS tactic, it’s definately not stable behavior.
Another comment sent my way was that OpenBSD doesn’t actually listen externally on port 25 when sendmail is running; it’s only running as an internal MTA. Yeah, sorry about that, dumb assumption on my part.
While the OpenBSD results didn’t compare to well with the other SPARC64 operating systems performance-wise, it doesn’t detract from its usefulness, especially as a firewall/router system. The test was only MySQL, and with MySQL running, it’s all that much more of a useful system and would make a good development system in addition to a great firewall/router.
If you would like to see your thoughts or experiences with technology published, please consider writing an article for OSNews.