pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Scott Carey <scott@richrelevance.com>
To: grant@amadensor.com <grant@amadensor.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Subject: Re: Fun little performance IMPROVEMENT...
Date: Fri, 21 Jan 2011 13:10:50 -0800
Message-ID: <C95F3502.1B8D9%scott@richrelevance.com> (raw)
In-Reply-To: <6db0dcf63cdcbdce27f8f941de3e623d.squirrel@grant.boldlygoingnowhere.org>



On 1/21/11 12:23 PM, "grant@amadensor.com" <grant@amadensor.com> wrote:

>> grant@amadensor.com writes:
>>> Here is the fun part.   When running 8 threads spinning calculating
>>> square
>>> roots (using the stress package), the full scan returned consistently
>>> 60%
>>> faster than the machine with no load.
>>
>> Possibly the synchronized-seqscans logic kicking in, resulting in this
>> guy not having to do all his own I/Os.  It would be difficult to make
>> any trustworthy conclusions about performance in such cases from a view
>> of only one process's results --- you'd need to look at the aggregate
>> behavior to understand what's happening.
>>
>>             regards, tom lane
>>
>My though was that either:
>
>1)  It was preventing some other I/O or memory intensive process from
>happening, opening the resources up.
>2)  It was keeping the machine busy from the hypervisor's point of view,
>preventing it from waiting for a slot on the host machine.

My guess is its something hypervisor related.   If this happened on direct
hardware I'd be more surprised.  Hypervisors have all sorts of stuff going
on, like throttling the number of CPU cycles a vm gets.  In your idle
case, your VM might effectively occupy 1Ghz of a CPU, but 2Ghz in the
loaded case.

>3)  The square roots happen quickly, resulting in more yields, and
>therefore more time slices for my process than if the system was in its
>idle loop.
>
>Any way you look at it, it is fun and interesting that a load can make
>something unrelated happen more quickly.   I will continue to try to find
>out why it is the case.
>
>
>
>-- 
>Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
>To make changes to your subscription:
>http://www.postgresql.org/mailpref/pgsql-performance




view thread (10+ messages)  latest in thread

Message-ID: <C95F3502.1B8D9%scott@richrelevance.com>
Permalink:  ../C95F3502.1B8D9%25scott@richrelevance.com/
Also on:    postgresql.org/message-id/C95F3502.1B8D9%scott@richrelevance.com

 · 

reply

Reply instructions:

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

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: scott@richrelevance.com, grant@amadensor.com, tgl@sss.pgh.pa.us
  Subject: Re: Fun little performance IMPROVEMENT...
  In-Reply-To: <C95F3502.1B8D9%scott@richrelevance.com>

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

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox