Re: 7.4b1 vs 7.3.4 performance
От | Shridhar Daithankar |
---|---|
Тема | Re: 7.4b1 vs 7.3.4 performance |
Дата | |
Msg-id | 3F4604E0.5912.4BAD6F9@localhost обсуждение исходный текст |
Ответ на | Re: 7.4b1 vs 7.3.4 performance (expect <expect@ihubbell.com>) |
Список | pgsql-general |
On 21 Aug 2003 at 8:22, expect wrote: > On Thu, 21 Aug 2003 12:55:35 +0530 > Shridhar Daithankar <shridhar_daithankar@persistent.co.in> wrote: > > > Both 7.3.4 and 7.4 had: > > > > > > 3072 buffers > > > 4096K sort memory > > > 16384K vacuum memory > > > > Since you weren't running any huge sorts thr. pgbench and vacuum, canyou drop > > last two to half of these and check? > Just trying to learn a little more about pg perf. behavior.... > Are you suggesting that with less memory to "manage" that pg > will run more efficiently? Yes. If that is not required, bumping them unnecessarily could have unwanted side effects at times. > > > fsync false > > > 16 WAL buffers > > > statistics on > > > > I would put more WAL buffers. 32-64 maybe.. > > It would be interesting to see 10 or 20 plateaus for that number or > at least up to the point of diminishing returns for the load that's applied. > Or maybe it wouldn't? Maybe it scales. WAL is where are transactions are channelled. Pgbench is heavy on transactions I understand. So if you are trying to tight-loop pgbench for exceedingly large number of transactions, WAL will be hit like anything and likely become bottleneck. If you have bit bigger WAL buffers, then the bottleneck would be slightly eases but but still it will eb limited by disk IO bandwidth. Having too many smalll transactions too rapidly can not deliver performance unless you have proportionate disk bandwidth. You need to size them appropriately if possible. HTH Bye Shridhar -- It is more rational to sacrifice one life than six. -- Spock, "The Galileo Seven", stardate 2822.3
В списке pgsql-general по дате отправления: