Skip site navigation (1) Skip section navigation (2)

Re: Perf regression in 2.6.32 (Ubuntu 10.04 LTS)

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Greg Smith <greg(at)2ndquadrant(dot)com>
Cc: Domas Mituzas <midom(dot)lists(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Perf regression in 2.6.32 (Ubuntu 10.04 LTS)
Date: 2010-09-27 15:28:13
Message-ID: AANLkTimPCHCb56Tdid_h9v6jZtCw5dn-1Sjz_r_=5+C2@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Mon, Sep 13, 2010 at 12:05 PM, Greg Smith <greg(at)2ndquadrant(dot)com> wrote:
> Domas Mituzas wrote:
>>
>> I've been playing around today a lot with sysbench, and observed that
>> 2.6.32 kernel supplied by Ubuntu is having perf regression with PG (which
>> does not affect MySQL), compared to 2.6.28 builds I have.
>> What I observed can be seen in a paste at
>> http://p.defau.lt/?8_GQV82Pz3_SDZbNOdP93Q (db12 is 2.6.28, db20 is 2.6.32 -
>> 2.6.32-24-server).
>> Machines are two socket quad-opterons 2356s.
>> oprofile output can be seen at http://p.defau.lt/?OIR1vDFK4cze_fmBTQbV9w -
>> system has >20% of idle cpu, which is somewhere in the top symbol :)
>>
>
> Are you using the same filesystem setup on both setups?  And regardless,
> what is that filesystem?  We know that between 2.6.28 and 2.6.32 the kernel
> improved how it handles fsync requests in a good way from a reliability
> perspective (to fix bugs that could cause data loss before), particularly on
> ext4, so it's possible the regression you're seeing is just the expense of
> handling things properly.
>
> If you already have sysbench on there, I'd suggest comparing the two systems
> by seeing how fast each can execute fsync requests:
>
> sysbench --test=fileio --file-fsync-freq=1 --file-num=1
> --file-total-size=16384 --file-test-mode=rndwr run | grep "Requests/sec"
>
> To help distinguish whether this regression might be coming from the already
> known changes in that area, or if it's instead from something that's
> impacting CPU efficiency.
>
> Also, it's easy to see a performance change of this size just from the
> database files being on a different part of the disk if you didn't control
> for that.  Disks are almost twice as fast at their beginning than their end
> nowadays.

Greg, have you run into any other evidence suggesting a problem with 2.6.32?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

In response to

Responses

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2010-09-27 15:28:30
Subject: Re: Improving prep_buildtree used in VPATH builds
Previous:From: Llewellyn, Mark (ADP DSI)Date: 2010-09-27 15:27:03
Subject: Re: BUG #5650: Postgres service showing as stopped when in fact it is running

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group