My takeaways from this:
- Kernel 3.2 is in fact lethally bad.
- Kernel 3.13 is the best out of kernel 3.X so far. I hope that this can be credited to the PostgreSQL team's work with the LFS/MM group.
- No 3.X kernel yet has quite the throughput of 2.6.32, at least at moderate memory sizes and core counts.
- However, kernel 3.13 has substantially lower write volumes at almost the same throughput. This means that if you are write-bound on IO, 3.13 will improve your performance considerably.
- If your database is mostly-reads and highly concurrent, consider enabling
kernel.sched_autogroup_enabled.
https://www.kernel.org/category/releases.html
ReplyDelete3.13 does not Longterm!
what about 3.14? Greg Kroah-Hartman seems like a true mainterner.
I would love to see the same test with CentOS/RHEL 6 and 7 included.
ReplyDeleteIt could be very useful to have CentOS 5 included too.
ReplyDeleteBe my guest! I'll happily link to you if you publish it.
DeleteThis reminds me of all the threads I started in the performance mailing list regarding 3.2 being terrible. We got around parts of it by adjusting scheduler migration cost, and other kernel knobs, but the memory management was abhorrent and completely impossible to circumvent.
ReplyDeleteWhat's interesting is that we saw almost 15% better improvement by disabling autogrouping on an 80% read server. Of course, that too was on the 3.2 kernel, so who knows what we were actually fixing. :p
Shaun: Yes, and we just tested autogrouping on high-speed replicas, and found no difference at all. I suspect that it depends on the exact nature of the queries and some of your other settings.
Delete