Re: PostgreSQL 8.4 performance tuning questions
От | PFC |
---|---|
Тема | Re: PostgreSQL 8.4 performance tuning questions |
Дата | |
Msg-id | op.ux3rv6ldcigqcu@soyouz обсуждение исходный текст |
Ответ на | Re: PostgreSQL 8.4 performance tuning questions (Scott Carey <scott@richrelevance.com>) |
Список | 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 по дате отправления: