Re: PostgreSQL 8.4 performance tuning questions

From: PFC <lists(at)peufeu(dot)com>
To: "Scott Carey" <scott(at)richrelevance(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: PostgreSQL 8.4 performance tuning questions
Date: 2009-08-03 20:15:32
Message-ID: op.ux3rv6ldcigqcu@soyouz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance


> I get very different (contradictory) behavior. Server with fast RAID,
> 32GB
> RAM, 2 x 4 core 3.16Ghz Xeon 54xx CPUs. CentOS 5.2
> 8.3.6

That's a very different serup from my (much less powerful) box, so that
would explain it...

> No disk wait time during any test. One test beforehand was used to prime
> the disk cache.
> 100% CPU in the below means one core fully used. 800% means the system
> is
> fully loaded.
>
> pg_dump > file (on a subset of the DB with lots of tables with small
> tuples)
> 6m 27s, 4.9GB; 12.9MB/sec
> 50% CPU in postgres, 50% CPU in pg_dump

If there is no disk wait time, then why do you get 50/50 and not 100/100
or at least 1 core maxed out ? That's interesting...

COPY annonces TO '/dev/null';
COPY 413526
Temps : 13871,093 ms

\copy annonces to '/dev/null'
Temps : 14037,946 ms

time pg_dump -Fc -t annonces -U annonces --compress=0 annonces >/dev/null
real 0m14.596s
user 0m0.700s
sys 0m0.372s

In all 3 cases postgres maxes out one core (I've repeated the test until
all data was cached, so there is no disk access at all in vmstat).
Size of dump is 312MB.

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Kevin Grittner 2009-08-03 20:44:30 Re: Query help
Previous Message Subbiah Stalin-XCGF84 2009-08-03 20:12:50 Re: Query help