Re: WAL prefetch

Поиск
Список
Период
Сортировка
От Ants Aasma
Тема Re: WAL prefetch
Дата
Msg-id CA+CSw_tsQ2i_0Vpv8gg7qoHCPYXmU+HKCU1jakLA_EBwktCfbw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: WAL prefetch  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Ответы Re: WAL prefetch  (Konstantin Knizhnik <k.knizhnik@postgrespro.ru>)
Список pgsql-hackers
On Tue, Jun 19, 2018 at 4:04 PM Tomas Vondra <tomas.vondra@2ndquadrant.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]
https://www.postgresql.org/message-id/CAHyXU0yiVvfQAnR9cyH=HWh1WbLRsioe=mzRJTHwtr=2azsTdQ@mail.gmail.com

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.

Regards,
Ants Aasma

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jeremy Finzel
Дата:
Сообщение: Re: found xmin from before relfrozenxid on pg_catalog.pg_authid
Следующее
От: Robert Haas
Дата:
Сообщение: Re: server crashed with TRAP: FailedAssertion("!(!parallel_aware || pathnode->path.parallel_safe)"