Re: RFC: replace pg_stat_activity.waiting with something more descriptive - Mailing list pgsql-hackers
From | Alexander Korotkov |
---|---|
Subject | Re: RFC: replace pg_stat_activity.waiting with something more descriptive |
Date | |
Msg-id | CAPpHfdscDTQxfj7ViqSJ3E5Ora9Zv_CrX=dk4xL+L7sHufdNPQ@mail.gmail.com Whole thread Raw |
In response to | Re: RFC: replace pg_stat_activity.waiting with something more descriptive (Amit Kapila <amit.kapila16@gmail.com>) |
List | pgsql-hackers |
On Mon, Sep 14, 2015 at 2:25 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
On Mon, Sep 14, 2015 at 3:02 PM, Alexander Korotkov <aekorotkov@gmail.com> wrote:On Sat, Sep 12, 2015 at 3:24 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:On Fri, Aug 14, 2015 at 7:23 PM, Alexander Korotkov <aekorotkov@gmail.com> wrote:
>
> On Thu, Aug 6, 2015 at 1:01 PM, Ildus Kurbangaliev <i.kurbangaliev@postgrespro.ru> wrote:
>>
>>
>> I've looked deeper and I found PgBackendStatus to be not a suitable
>> place for keeping information about low level waits. Really, PgBackendStatus
>> is used to track high level information about backend. This is why auxiliary
>> processes don't have PgBackendStatus, because they don't have such information
>> to expose. But when we come to the low level wait events then auxiliary
>> processes are as useful for monitoring as backends are. WAL writer,
>> checkpointer, bgwriter etc are using LWLocks as well. This is certainly unclear
>> why they can't be monitored.
>>
>> This is why I think we shoudn't place wait event into PgBackendStatus. It
>> could be placed into PGPROC or even separate data structure with different
>> concurrency model which would be most suitable for monitoring.
>
>
> +1 for tracking wait events not only for backends
>
> Ildus, could you do following?
> 1) Extract LWLocks refactoring into separate patch.
> 2) Make a patch with storing current wait event information in PGPROC.
>Now as Robert has committed standardization of lwlock names incommit - aa65de04, let us try to summarize and work on remaining partsof the patch. So I think now the next set of work is as follows:1. Modify the tranche mechanism so that information about LWLockscan be tracked easily. For this already there is some discussion, ideasand initial patch is floated in this thread and there doesn't seem to be muchconflicts, so we can write the patch for it. I am planning to write or modifythe existing patch unless you, IIdus or anyone has objections or want towrite it, please let me know to avoid duplication of work.2. Track wait_event in pg_stat_activity. Now here the main point wherewe doesn't seem to be in complete agreement is that shall we keep itas one byte in PgBackendStatus or use two or more bytes to storewait_event information and still there is another point made by you tostore it in PGProc rather than in PgBackendStatus so that we can displayinformation of background processes as well.Now as a matter of consensus, I think Tom has raised a fair point [1] againststoring this information in PGProc and I feel that it is relatively lessimportant to have such information about background processes and thereason for same is explained upthread [2]. About having more than one-byteto store information about various wait_events, I think now we will not havemore than 100 or so events to track, do you really think that anytime in forseeablefuture we will have more than 256 important events which we would like to track?So I think about this lets first try to build the consensus and then attempt towrite or modify the patch.In order to build the consensus we need the roadmap for waits monitoring.Would single byte in PgBackendStatus be the only way for tracking wait events? Could we have pluggable infrastructure in waits monitoring: for instance, hooks for wait event begin and end?Limit of 256 wait events is probably OK. But we have no room for any additional parameters of wait event. For instance, if you notice high contention for buffer content lock then it would be nice to figure out: how many blocks are involved?, which blocks? We need to track additional parameters in order to answer this question.We can track additional parameters by default or based on someparameter, but do you think that tracking backends wait_eventinformation as proposed hinders in any which way the future extensionsin this area? The point is that detailed discussion of other parameterscould be better done separately unless you think that this can blockfuture enhancements for waits monitoring.
Yes, I think this can block future enhancements for waits monitoring.
You're currently proposing to store current wait event in just single byte. And this is single byte not because of space economy, it is so by concurrency design.
Isn't it natural to ask you how are we going to store something more about current wait event? Should we store additional parameters separately from current wait event? Does it make sense?
Or should we move current wait event away from BgBackendStatus. If so, why place it there?
I see wait monitoring of overalldatabase as a really valuable feature, but not able to see compellingneed to sort out everything before this patch. Having said that, I am openfor discussion if you want specific things to be sorted out before moving further.
I think we need to be sure that we can move further in waits monitoring without reverting this.
------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
pgsql-hackers by date: