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
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 |