Re: Database Stalls

From: José Arthur Benetasso Villanova <jose(dot)arthur(at)gmail(dot)com>
To: Justin Pryzby <pryzby(at)telsasoft(dot)com>
Cc: Mok <gurmokh(at)gmail(dot)com>, pgsql-performance(at)lists(dot)postgresql(dot)org
Subject: Re: Database Stalls
Date: 2023-01-30 18:10:54
Message-ID: CA+soXCNgNGd02d-Abi1zp4V0Fii5HuWN9O1w-PUYJ16cdG=4kw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Mon, Jan 30, 2023 at 2:51 PM Justin Pryzby <pryzby(at)telsasoft(dot)com> wrote:

> On Mon, Jan 30, 2023 at 05:47:49PM +0000, Mok wrote:
> > Hi,
> >
> > We've started to observe instances of one of our databases stalling for a
> > few seconds.
> >
> > We see a spike in wal write locks then nothing for a few seconds. After
> > which we have spike latency as processes waiting to get to the db can do
> > so.
> >
> > There is nothing in the postgres logs that give us any clues to what
> could
> > be happening, no locks, unusually high/long running transactions, just a
> > pause and resume.
> >
> > Could anyone give me any advice as to what to look for when it comes to
> > checking the underlying disk that the db is on?
>
> What version postgres? What settings have non-default values ?
>
>
> What OS/version? What environment/hardware? VM/image/provider/...
>
>
>
> Have you enabled logging for vacuum/checkpoints/locks ?
>
> https://wiki.postgresql.org/wiki/Slow_Query_Questions
>
>
> In addition to previous questions, if possible, a SELECT * FROM
pg_stat_activity at the moment of the stall. The most important information
is the wait_event column. My guess is the disk, but just the select at the
right moment can answer this.

--
José Arthur Benetasso Villanova

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Shiv Iyer 2023-01-30 18:47:33 Re: Database Stalls
Previous Message Justin Pryzby 2023-01-30 17:51:18 Re: Database Stalls