Remove the comment on the countereffectiveness of large shared_buffers on Windows

From: "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>
To: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Remove the comment on the countereffectiveness of large shared_buffers on Windows
Date: 2016-09-20 02:45:51
Message-ID: 0A3221C70F24FB45833433255569204D1F5EE995@G01JPEXMBYT05
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello,

> From: pgsql-hackers-owner(at)postgresql(dot)org
> [mailto:pgsql-hackers-owner(at)postgresql(dot)org] On Behalf Of Magnus Hagander
> On Wed, Aug 24, 2016 at 4:35 AM, Tsunakawa, Takayuki
> <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> wrote:
> As a similar topic, I wonder whether the following still holds true,
> after many improvements on shared buffer lock contention.
>
> https://www.postgresql.org/docs/devel/static/runtime-config-re
> source.html
>
> "The useful range for shared_buffers on Windows systems
> is generally from 64MB to 512MB."
>
>
>
>
> Yes, that may very much be out of date as well. A good set of benchmarks
> around that would definitely be welcome.

I'd like to propose the above-mentioned comment from the manual. The patch is attached.

I ran read-only and read-write modes of pgbench, and could not see any apparent decrease in performance when I increased shared_buffers. The scaling factor is 200, where the database size is roughly 3GB. I ran the benchmark on my Windows 10 PC with 6 CPU cores and 16GB of RAM. The database and WAL is stored on the same HDD.

<<Test batch file>>
@echo off
for %%s in (256MB 512MB 1GB 2GB 4GB) do (
pg_ctl -w -o "-c shared_buffers=%%s" start
pgbench -c18 -j6 -T60 -S bench >> g:\b.txt 2>&1
pg_ctl -t 3600 stop
)

<<Select-only (with -S)>>
shared_buffers tps
256MB 63056
512MB 63918
1GB 65520
2GB 66840
4GB 68270

<<Read-write (without -S)>>
shared_buffers tps
256MB 1138
512MB 1187
1GB 1571
2GB 1650
4GB 1598

Regards
Takayuki Tsunakawa

Attachment Content-Type Size
win_shrdbuf_perf.patch application/octet-stream 830 bytes

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2016-09-20 03:07:15 Re: Speed up Clog Access by increasing CLOG buffers
Previous Message Craig Ringer 2016-09-20 01:54:28 Re: [PATCH] Transaction traceability - txid_status(bigint)