|From:||"Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>|
|Subject:||Remove the comment on the countereffectiveness of large shared_buffers on Windows|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
> 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.
> "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>>
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)>>
<<Read-write (without -S)>>
|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)|