Since they switched to the Completely Fair Scheduler [wikipedia.org] to improve performance then it means one or two things. Either they have failed, as it seems to run slower than earlier Linux versions in the BSD test, or the tests that BSD chose are "untypical", maybe selected to show a particular advantage to BSD. I don't have the expertise to tell which, but I would be happier seeing some benchmarks from an independent source rather than BSD.
The article is probably misleading (surprise, surprise), as the tuning documentation for PostgreSQL *states* that good IO performance has more of an impact than good CPU performance. Additionally, some other information I've read (search for postgres tuning/optimi(z|s)ation online) recommends FreeBSD because of its strong IO performance. I'll go out on a limb and assume that MySQL's performance attributes are similar.
In my opinion, the article summary is a pretty big red herring because the SMP performance may not have a huge impact on the result.
Generally speaking, MySQL doesn't perform that much better than Postgresql if the former is using the MyISAM engine. Turn on InnoDB (for silly things like transactions and foreign keys) and Postgresql typically wins out. Of course, if you're just using your database as a data store--an easy way to store data with convenient, known methods for finding and updating that data, you may be ok with just MySQL/MyISAM. If you're using your database as an actual, relational database and looking for data integrity e
Yep, it's usually a good idea to read the whole article.
The telling slide though is 17, from the summary, the so-called "Latest Linux Kernel" is Linux 2.6.23.0.214.rc8.git2.fc8, a release candidate on an unstable branch of the kernel. Even with that being the case, the graph shows a slight edge given to FreeBSD, until there's a blip in the Linux results between 9-16 threads, after which the performance levels out. The fact remains, while the results for FreeBSD are clearly in FreeBSD's favour after 8 thre
That doesn't really legitimize the claims made in the summary however. This is./ though, so probably not worth making a big fuss about it. Anyway, even last year I was interested in giving FreeBSD a try as our DB host but I haven't had time. It's just a shame that most readers aren't going to get much useful information from the summary or discussion.
the tuning documentation for PostgreSQL *states* that good IO performance has more of an impact than good CPU performance
This is often, but not always the case -- it depends on the nature of the query workload. In this case, the benchmark was done using read-only queries, specifically for the purpose of minimizing the I/O requirements and therefore focusing on CPU performance.
The closest to perfection a person ever comes is when he fills out a job
application form.
-- Stanley J. Randall
Bad news for Linux? (Score:2, Insightful)
Re:Bad news for Linux? (Score:5, Insightful)
In my opinion, the article summary is a pretty big red herring because the SMP performance may not have a huge impact on the result.
Re: (Score:2)
Of course, if you're just using your database as a data store--an easy way to store data with convenient, known methods for finding and updating that data, you may be ok with just MySQL/MyISAM. If you're using your database as an actual, relational database and looking for data integrity e
Re: (Score:2)
Slide 10 out of 37 [freebsd.org] (emphasis mine -mi):
Re: (Score:2)
The telling slide though is 17, from the summary, the so-called "Latest Linux Kernel" is Linux 2.6.23.0.214.rc8.git2.fc8, a release candidate on an unstable branch of the kernel. Even with that being the case, the graph shows a slight edge given to FreeBSD, until there's a blip in the Linux results between 9-16 threads, after which the performance levels out. The fact remains, while the results for FreeBSD are clearly in FreeBSD's favour after 8 thre
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
This is often, but not always the case -- it depends on the nature of the query workload. In this case, the benchmark was done using read-only queries, specifically for the purpose of minimizing the I/O requirements and therefore focusing on CPU performance.