All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jagdish Motwani <jagdish.motwani@elitecore.com>
To: Andres Freund <andres@anarazel.de>
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: performance degradation on kernel upgrade (due to commit ab0a9735e06914ce4d2a94ffa41497dbc142fe7f)
Date: Mon, 24 Sep 2012 11:15:02 +0530	[thread overview]
Message-ID: <505FF35E.6020506@elitecore.com> (raw)
In-Reply-To: <201209211625.42895.andres@anarazel.de>

On 09/21/2012 07:55 PM, Andres Freund wrote:
> Hi,
>
> On Friday, September 21, 2012 03:47:56 PM Jagdish Motwani wrote:
>> Recently i upgraded my kernel from 2.6.29.6 to 2.6.35.14.
>>
>> After upgrading i got very poor performance on my postgre database.
>>
>>
>> My test.sql contains 10000 postgre insert query
>>
>>
>> Linux  2.6.29.6
>>
>> time psql -U user -d database -f test.sql  > /dev/null
>> real    0m 7.23s
>> user    0m 0.38s
>> sys     0m 0.12s
>>
>>
>>
>> Linux  2.6.35.14
>>
>> # time psql -U user -d database -f test.sql  > /dev/null
>> real    1m 4.05s
>> user    0m 0.44s
>> sys    0m 0.12
> How do the results to this look if you use psql -1/--single-transaction?
Using single transaction solves the problem - but that's not what i 
really want.
>
>> I even tried Linux 3.5.4 and got similar results.
>>
>> Using git bisect, i got commit ab0a9735e06914ce4d2a94ffa41497dbc142fe7f
>>
>> Is it a behavior change or am i missing something? Are there any
>> workarounds for this?
> I guess youre using some form of virtualization? I think what youre observing
> is just that access via raw devices previously lied about consistency. As the
> commit observes several virtualization solutions can use raw device access.
>
> If all those 10000 inserts above happen in individual transactions - which
> would happen if youre not using transactions explicitly -  each and every one
> of them will cause a single disk write if they are executed sequentially.
> A typical rotating disks can do between 80-160 such writes. If you devide 10k
> transactions by 150 synchronous writes a second you get ~66s which pretty
> nicely fits your time above.
>
> If you don't care about loosing a very small amount of transactions (up to a
> second with the default settings) you can disable the synchronous_commit
> setting in postgres. No earlier commits/changes will be lost/corrupted.
> You can change that setting per transaction, per session/connection, per user,
> per database or globally.
>
> Greetings,
>
> Andres
Thanks Andres,

I disabled synchronous_commit, and got results similar to 2.6.32.

Regards,
Jagdish Motwani

      reply	other threads:[~2012-09-24  5:39 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-21 13:47 performance degradation on kernel upgrade (due to commit ab0a9735e06914ce4d2a94ffa41497dbc142fe7f ) Jagdish Motwani
2012-09-21 14:17 ` Jeff Moyer
2012-09-21 14:25 ` performance degradation on kernel upgrade (due to commit ab0a9735e06914ce4d2a94ffa41497dbc142fe7f) Andres Freund
2012-09-24  5:45   ` Jagdish Motwani [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=505FF35E.6020506@elitecore.com \
    --to=jagdish.motwani@elitecore.com \
    --cc=andres@anarazel.de \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.