Re: Some performance testing?

The 3.10 mainline had a bug which crashes on boot for us, I think it was the network card driver for the R620. Can't recall.
The equipment is in continual use so unfortunately we can't test other kernels at the moment but hopefully someone else may be interested.
It's probably valuable to compare against 3.19 too for anyone who doesn't want to delve into kernel archeology.

Kernel performance gains will be sensitive to things like VM settings, scheduler settings, NUMA, hardware choice, BIOS settings etc, use of virtualisation, so it depends which codepaths you end up running. So it may not be meaningful to compare kernels without a range of system configurations to measure against. ie. Your mileage will probably vary depending on how far you've tuned your disk configuration, memory, etc.

Graeme Bell

On 09 Apr 2015, at 17:15, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> wrote:

> On Thu, Apr 9, 2015 at 7:35 AM, Graeme B. Bell <grb(at)skogoglandskap(dot)no> wrote:
>> ext4 settings
>>
>> ext4, nobarrier
>> noatime+nodatime,
>> stripe&stride aligned between raid10 & ext4 correctly.
>>
>>
>> Some other useful things to know
>>
>> -- h710p
>> readahead disabled on H710P
>> writeback cache enabled on H710P
>> Direct IO enabled on H710P
>>
>> -- os filesystem settings
>> linux readahead enabled (16384),
>> nr_requests=975
>> NOOP scheduler
>> non-NUMA
>>
>> -- pg
>> io_concurrency on
>> async commit.*** see below!
>>
>> All settings were kept identical on the server before and after the kernel change, so this performance increase can be entirely attributed to the newer kernel and its synergies with our configuration. 3.18 contains about 5-10 years of linux kernel development vs. 2.6 kernels (except where backported).
>>
>> I have conducted quite a lot of plug-pull testing with diskchecker.pl, and rather a lot of testing of scheduling/IO/RAID controller/etc parameters. The OS/RAID controller/file system settings are as fast as I've been able to achieve without compromising database integrity (please note: this server can run async_commit because of the work we use it for, but we do not use that setting on our other main production servers).
>>
>> Our local DBs run extremely nicely for all our normal queries which involve quite a mix of random small IO and full-table operations on e.g. 20GB+ tables , so they're not optimised for pgbench specifically.
>
> It would be handy to see a chart comparing 3.11, 3.13 and 3.18 as
> well, to see if most / any of those performance gains came in earlier
> kernels, but after 2.6 or 3.2 etc.
>
> Can confirm that for pg purposes, 3.2 is basically broken in some not
> to great ways. We've had servers that were overloaded at load factors
> of 20 or 30 drop down to 5 or less with just a change from 3.2 to
> 3.11/3.13 on ubuntu 12.04