Re: wait events for disk I/O

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: wait events for disk I/O
Date: 2017-03-07 02:09:55
Message-ID: CAA4eK1KDs+AD8-h=nX-Ht+yv66OJU1jc5ZeWcby9MxSbPKDrFw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Mar 7, 2017 at 5:27 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Mon, Mar 6, 2017 at 3:27 AM, Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com> wrote:
>> Yes, I thought of adding wait event only for the sync but then recording the
>> wait event for both write and sync. I understand that OS level writes are
>> cheap but it still have some cost attached to that. Also I thought for the
>> monitoring tool being develop using this wait events, will have more useful
>> capture data if we try to collect as much info as we can. Or may be not.
>>
>> I am open for other opinion/suggestions.
>
> Writes are NOT always fast. I've seen cases of write() blocking for
> LONG periods of time on systems that are in the process of failing, or
> just busy. So I think we certainly want to advertise a wait event for
> those.
>

Sure, if you think both Writes and Reads at OS level can have some
chance of blocking in obscure cases, then we should add a wait event
for them.

> Likewise, I agree that the prefetch call probably SHOULDN'T block, but
> just because it shouldn't doesn't mean it never will.
>
> I think somebody should try a pgbench run with this patch applied,
> using a scale factor greater than shared_buffers, and generate a wait
> event profile, just to see if these are showing up and how often.
>

Yeah, that makes sense to me and we should try for both read-write and
read-only tests.

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2017-03-07 02:11:53 Re: Enabling replication connections by default in pg_hba.conf
Previous Message Craig Ringer 2017-03-07 02:01:53 Re: Restricting maximum keep segments by repslots