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