Re: some longer, larger pgbench tests with various performance-related patches
От | Robert Haas |
---|---|
Тема | Re: some longer, larger pgbench tests with various performance-related patches |
Дата | |
Msg-id | CA+TgmoY8tVMBr3d3=hATTeDjODinvOQ9WzCrn4_owG9dBwezjw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: some longer, larger pgbench tests with various performance-related patches (Jeff Janes <jeff.janes@gmail.com>) |
Ответы |
Re: some longer, larger pgbench tests with various
performance-related patches
Re: some longer, larger pgbench tests with various performance-related patches |
Список | pgsql-hackers |
On Wed, Jan 25, 2012 at 12:00 PM, Jeff Janes <jeff.janes@gmail.com> wrote: > On Tue, Jan 24, 2012 at 12:53 PM, Robert Haas <robertmhaas@gmail.com> wrote: >> Early yesterday morning, I was able to use Nate Boley's test machine >> do a single 30-minute pgbench run at scale factor 300 using a variety >> of trees built with various patches, and with the -l option added to >> track latency on a per-transaction basis. All tests were done using >> 32 clients and permanent tables. The configuration was otherwise >> identical to that described here: >> >> http://archives.postgresql.org/message-id/CA+TgmoboYJurJEOB22Wp9RECMSEYGNyHDVFv5yisvERqFw=6dw@mail.gmail.com > > Previously we mostly used this machine for CPU benchmarking. Have you > previously described the IO subsystem? That is becoming relevant for > these types of benchmarks. For example, is WAL separated from data? I actually don't know much about the I/O subsystem, but, no, WAL is not separated from data. I believe $PGDATA is on a SAN, but I don't know anything about its characteristics. >> By doing this, I hoped to get a better understanding of (1) the >> effects of a scale factor too large to fit in shared_buffers, > > In my hands, the active part of data at scale of 300 fits very > comfortably into 8GB shared_buffers. > > Indeed, until you have run a very long time so that pgbench_history > gets large, everything fits in 8GB. Hmm, my mistake. Maybe I need to crank up the scale factor some more.This is why good benchmarking is hard. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: