Re: wait events for disk I/O

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: wait events for disk I/O
Date: 2017-03-07 00:01:20
Message-ID: CAB7nPqR0MDbeQj2LJ7V=pad4DGV8-e-cNQns1aq4CftinfgYag@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Mar 7, 2017 at 8:57 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.

+1. I see that quite often really happens, and a lot particularly on
overloaded VMs. Having to debug such systems until you notice that
what is slow is just the underlying system is no fun. So being able to
show up an event state in memory where we can say that things are
stuck on I/O just with PG interface can really help in diagnostics
without having to look at storage-level logs for a first impression.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2017-03-07 00:04:19 Re: Performance degradation in TPC-H Q18
Previous Message Robert Haas 2017-03-06 23:59:02 Re: Performance degradation in TPC-H Q18