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.
Benchmarks are almost but not completely useless. In this particular setup, FBSD 7.0 runs postgres doing some specific set of queries faster than Linux.
Its a safe bet Linux will do some other set of things faster than FreeBSD does them, possibly even another specific set of PostgreSQL queries for that matter. Linux is definately more concerned with desktop app performance. I can say this safely because Linux actually cares about it, FreeBSD does not. Its there to serve, not run X. It will run X, and if they see a way to make performance better for the desktop apps AND the server apps, then it may go in the source tree. If its going to hurt the server side, don't bet on it.
While I use FreeBSD for my servers because its got a clean filesystem layout and is designed to be a server OS, I'd be willing to bet that someone with deep knowledge of PostgreSQL on Linux could give it a run for its money by tweaking the kernel for server performance.
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.
For one, CFQ is not supposed to be an optimized I/O scheduler for database loads. That's where the Deadline scheduler comes in. You wouldn't want a "Fair" scheduler on your database server, as you would end up putting the database in I/O wait to handle lower priority processes.
As t'other poster pointed out; CFS = Completely Fair Scheduling = CPU scheduler = what process gets how much of the CPU CFQ = Completely Fair Queuing = I/O scheduler = what process gets how much of the hard disc
FWIW, on our database loads at least, I find that whilst deadline tends to give the lowest single transaction rate, CFQ gives better overall performance (i.e. more transactions served) over a given time period. Anyone tried the CFQ, deadline and no-op schedulers on a solid state disc yet?
I don't have the expertise to tell which, but I would be happier seeing some benchmarks from an independent source rather than BSD.
This is entirely subjective, but:
FreeBSD 6 was quick on our dual two-core Opteron server, but upgrading to FreeBSD 7 gave a real kick in the pants. Honestly, the thing just screams along now. Our servers have never had Linux on them so I can't directly compare it on the same hardware, but can confidently say that 7 is a huge improvement over 6.
They didn't switch to the CFS to improve raw performance. The driving impetus behind the CFS was interactive performance. For some time schedulers have been "too fair" and treated batch and background tasks by the same rules as interactive tasks. The general way to improve interactive performance has been with shims and jimmies, like "nice -10 X". The real problem has been detecting *what* is an interactive job, and deciding whose priority to boost, especially without problems like priority inversions o
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:4, Insightful)
Its a safe bet Linux will do some other set of things faster than FreeBSD does them, possibly even another specific set of PostgreSQL queries for that matter. Linux is definately more concerned with desktop app performance. I can say this safely because Linux actually cares about it, FreeBSD does not. Its there to serve, not run X. It will run X, and if they see a way to make performance better for the desktop apps AND the server apps, then it may go in the source tree. If its going to hurt the server side, don't bet on it.
While I use FreeBSD for my servers because its got a clean filesystem layout and is designed to be a server OS, I'd be willing to bet that someone with deep knowledge of PostgreSQL on Linux could give it a run for its money by tweaking the kernel for server performance.
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.
Re:Bad news for Linux? (Score:5, Insightful)
Re: (Score:2)
Re: (Score:3, Informative)
CFS = Completely Fair Scheduling = CPU scheduler = what process gets how much of the CPU
CFQ = Completely Fair Queuing = I/O scheduler = what process gets how much of the hard disc
FWIW, on our database loads at least, I find that whilst deadline tends to give the lowest single transaction rate, CFQ gives better overall performance (i.e. more transactions served) over a given time period. Anyone tried the CFQ, deadline and no-op schedulers on a solid state disc yet?
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
I don't have the expertise to tell which, but I would be happier seeing some benchmarks from an independent source rather than BSD.
This is entirely subjective, but:
FreeBSD 6 was quick on our dual two-core Opteron server, but upgrading to FreeBSD 7 gave a real kick in the pants. Honestly, the thing just screams along now. Our servers have never had Linux on them so I can't directly compare it on the same hardware, but can confidently say that 7 is a huge improvement over 6.
Re: (Score:2)