On Thu, Apr 9, 2015 at 7:35 AM, Graeme B. Bell <grb@xxxxxxxxxxxxxxxxx> 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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
