Re: WAL prefetch

From: Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>
To: Ants Aasma <ants(dot)aasma(at)eesti(dot)ee>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, seanc(at)joyent(dot)com
Subject: Re: WAL prefetch
Date: 2018-06-19 14:50:39
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 19.06.2018 16:57, Ants Aasma wrote:
> On Tue, Jun 19, 2018 at 4:04 PM Tomas Vondra
> <tomas(dot)vondra(at)2ndquadrant(dot)com <mailto:tomas(dot)vondra(at)2ndquadrant(dot)com>>
> wrote:
> Right. My point is that while spawning bgworkers probably helps, I
> don't
> expect it to be enough to fill the I/O queues on modern storage
> systems.
> Even if you start say 16 prefetch bgworkers, that's not going to be
> enough for large arrays or SSDs. Those typically need way more
> than 16
> requests in the queue.
> Consider for example [1] from 2014 where Merlin reported how S3500
> (Intel SATA SSD) behaves with different effective_io_concurrency
> values:
> [1]
> Clearly, you need to prefetch 32/64 blocks or so. Consider you may
> have
> multiple such devices in a single RAID array, and that this device is
> from 2014 (and newer flash devices likely need even deeper queues).'
> For reference, a typical datacenter SSD needs a queue depth of 128 to
> saturate a single device. [1] Multiply that appropriately for RAID
> arrays.So

How it is related with results for S3500  where this is almost now
performance improvement for effective_io_concurrency >8?
Starting 128 or more workers for performing prefetch is definitely not

> Regards,
> Ants Aasma
> [1]

Konstantin Knizhnik
Postgres Professional:
The Russian Postgres Company

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-06-19 14:55:10 Fast default stuff versus pg_upgrade
Previous Message Robert Haas 2018-06-19 14:45:04 Re: Excessive CPU usage in StandbyReleaseLocks()