Re: PostgreSQL 8.4 performance tuning questions - Mailing list pgsql-performance

From PFC
Subject Re: PostgreSQL 8.4 performance tuning questions
Date
Msg-id op.ux3rv6ldcigqcu@soyouz
Whole thread Raw
In response to Re: PostgreSQL 8.4 performance tuning questions  (Scott Carey <scott@richrelevance.com>)
List 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.




pgsql-performance by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: Query help
Next
From: "Subbiah Stalin-XCGF84"
Date:
Subject: Re: Query help