Re: Some performance testing?

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
entirelyattributed 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.
 

Graeme Bell



On 09 Apr 2015, at 13:56, Przemysław Deć <przemyslaw.dec@linuxpolska.pl> wrote:

> Wow, thats huge performance gain.
> And it was on ext4?
> 
> -- 
> Linux Polska Sp. z o.o.
> Przemysław Deć - Senior Solutions Architect
> RHCSA, RHCJA, PostgreSQL Professional Certification
> mob: +48 519 130 141
> email: pd@linuxpolska.pl
> www.linuxpolska.pl 
>
___________________________________________________________________________________________________________________________
> Linux Polska Sp. z o. o.  Al. Jerozolimskie 123A (26 p.); 02-017 Warszawa; tel. (+48) 222139571; fax (+48)222139671
> KRS - 0000326158 Sąd Rejonowy dla M. St. Warszawy w Warszawie, XII Wydział Gospodarczy KRS
> Kapitał zakładowy wpłacony 1 000 500PLN;  NIP 7010181018;  REGON 141791601
> <Mail Attachment.jpeg>
> 
> 
> 2015-04-09 13:01 GMT+02:00 Graeme B. Bell <grb@skogoglandskap.no>:
> 
> From a measurement I took back when we did the upgrade:
> 
> performance with 2.6: (pgbench, size 100, 32 clients)
> 
> 48 651 transactions per second (read only)
> 6 504 transactions per second (read-write)
> 
> 
> performance with 3.18 (pgbench, size 100, 32 clients)
> 
> 129 303 transactions per second  (read only)
> 16 895 transactions (read-write)
> 
> 
> So that looks like 2.6x improvement to reads and writes. That was an 8 core xeon server with H710P and 4x crucial
M550SSDs in RAID, pg9.3.
 
> 
> Graeme Bell
> 
> 
> 
> 
> 
> On 09 Apr 2015, at 12:39, Przemysław Deć <przemyslaw.dec@linuxpolska.pl> wrote:
> 
> > Can you say how much faster it was?
> >
> > Przemek Deć
> >
> > 2015-04-09 11:04 GMT+02:00 Graeme B. Bell <grb@skogoglandskap.no>:
> > >
> > > Josh, there seems to be an inconsistency in your blog.  You say 3.10.X is
> > > safe, but the graph you show with the poor performance seems to be from
> > > 3.13.X which as I understand it is a later kernel.  Can you clarify which
> > > 3.X kernels are good to use and which are not?
> >
> > Sorry to cut in -
> >
> > So far we've found kernel 3.18 to be excellent for postgres 9.3 performance (pgbench + our own queries run much
fasterthan with the 2.6.32-504 centos 6 kernel, and we haven't encountered random stalls or slowness).
 
> >
> > We use elrepo to get prebuilt rpms of the latest mainline stable kernel (kernel-ml).
> >
> > http://elrepo.org/tiki/kernel-ml
> >
> > Graeme Bell
> >
> > --
> > Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
> > To make changes to your subscription:
> > http://www.postgresql.org/mailpref/pgsql-performance
> >
> 
>