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

Re: Perf regression in 2.6.32 (Ubuntu 10.04 LTS)

From: Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Perf regression in 2.6.32 (Ubuntu 10.04 LTS)
Date: 2010-09-28 03:37:09
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On 28/09/10 04:28, Robert Haas wrote:
> 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
>>> (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 -
>>> 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?

Not Greg (sorry), but this might be worth a look:



In response to


pgsql-hackers by date

Next:From: Robert HaasDate: 2010-09-28 03:57:16
Subject: Re: security hook on table creation
Previous:From: Robert HaasDate: 2010-09-28 03:33:19
Subject: Re: Help with User-defined function in PostgreSQL with Visual C++

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