Re: dbt-2 tuning results with postgresql-8.3.5

From: "Mark Wong" <markwkm(at)gmail(dot)com>
To: "Gregory Stark" <stark(at)enterprisedb(dot)com>
Cc: "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>, "Selena Deckelmann" <selenamarie(at)gmail(dot)com>, "Gabrielle Roth" <gorthx(at)gmail(dot)com>
Subject: Re: dbt-2 tuning results with postgresql-8.3.5
Date: 2008-12-23 03:36:05
Message-ID: 70c01d1d0812221936o57e54ec1j20b15309141672d5@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Mon, Dec 22, 2008 at 2:56 AM, Gregory Stark <stark(at)enterprisedb(dot)com> wrote:
> "Mark Wong" <markwkm(at)gmail(dot)com> writes:
>
>> Thanks for the input.
>
> In a more constructive vein:
>
> 1) autovacuum doesn't seem to be properly tracked. It looks like you're just
> tracking the autovacuum process and not the actual vacuum subprocesses
> which it spawns.

Hrm, tracking just the launcher process certainly doesn't help. Are
the spawned processed short lived? I take a snapshot of
/proc/<pid>/io data every 60 seconds. The only thing I see named
autovacuum is the launcher process. Or perhaps I can't read? Here is
the raw data of the /proc/<pid>/io captures:

http://207.173.203.223/~markwkm/community6/dbt2/baseline.1000.1/db/iopp.out

> 2) The response time graphs would be more informative if you excluded the
> ramp-up portion of the test. As it is there are big spikes at the low end
> but it's not clear whether they're really part of the curve or due to
> ramp-up. This is especially visible in the stock-level graph where it
> throws off the whole y scale.

Ok, we'll take note and see what we can do.

Regards,
Mark

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Mark Wong 2008-12-23 03:48:57 Re: dbt-2 tuning results with postgresql-8.3.5
Previous Message Mark Wong 2008-12-23 03:30:05 Re: dbt-2 tuning results with postgresql-8.3.5