Re: Some performance testing? - Mailing list pgsql-performance

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
maybe 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
settingsetc, use of virtualisation, so it depends which codepaths you end up running. So it may not be meaningful to
comparekernels without a range of system configurations to measure against. ie. Your mileage will probably vary
dependingon how far you've tuned your disk configuration, memory, etc.  

Graeme Bell

On 09 Apr 2015, at 17:15, Scott Marlowe <scott.marlowe@gmail.com> wrote:

> On Thu, Apr 9, 2015 at 7:35 AM, Graeme B. Bell <grb@skogoglandskap.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
beentirely attributed to the newer kernel  and its synergies with our configuration. 3.18 contains about 5-10 years of
linuxkernel 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/RAIDcontroller/etc parameters. The OS/RAID controller/file system settings are as fast as I've been able
toachieve without compromising database  integrity (please note: this server can run async_commit because of the work
weuse 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-tableoperations 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