No brtfs. We are going to try turning off synchronous_commit
temporarily to see if there are underlying I/O issues.
On Mon, 24 May 2021 at 22:59, Alexey M Boltenkov <padrebolt@yandex.ru> wrote:
>
> On 05/24/21 19:24, Christophe Pettus wrote:
> >
> >> On May 24, 2021, at 09:22, Bob Jolliffe <bobjolliffe@gmail.com> wrote:
> >>
> >> It is hard to say as it only happens for 30s couple of times per day.
> >> Everything does return to normal after the blocking transaction is
> >> committed. It could be a disk thing or even a network issue (the java
> >> app is on a different machine to the db). But I never saw
> >> transactions blocked in commit before so was wondering if there is any
> >> rational set of reasons why it might do that.
> > One thing you can check is to turn off synchronous_commit (understanding the possibility of "time loss" in the
eventof a system crash). If that mitigates the problem, the issue is likely the I/O subsystem blocking during the
fsync()operation.
> >
> >
> Just a question. Is there a btrfs(with compression maybe) around? 30
> seconds is a commit(file system) timeout for btrfs. Some processes like
> btrfs cleaner/allocate/worker on top of CPU/io use?
>
