| 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: | Whole Thread | Raw Message | 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.
| 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 |