public inbox for [email protected]  

help / color / mirror / Atom feed

From: Yura Sokolov <[email protected]>
To: Andres Freund <[email protected]>
Cc: James Pang <[email protected]>
Cc: [email protected]
Subject: Re: many sessions wait on LWlock WALWrite suddenly
Date: Tue, 15 Apr 2025 13:44:09 +0300
Message-ID: <[email protected]> (raw)
In-Reply-To: <l23ybh777m5u7goxpzznqtobbgxanm65k7yxqvstwh3lze5mn4@3x5dkdtwzpj6>
References: <CAHgTRffKZ8DvcFJHRpwkBMQZg5XLRbd5yWe+pSGeVRqbqXDsDg@mail.gmail.com>
	<[email protected]>
	<l23ybh777m5u7goxpzznqtobbgxanm65k7yxqvstwh3lze5mn4@3x5dkdtwzpj6>

15.04.2025 13:00, Andres Freund пишет:
> 1) Increasing NUM_XLOGINSERT_LOCKS allows more contention on insertpos_lck and
>    spinlocks scale really badly under heavy contention
> 
> I think we can redesign the mechanism so that there's an LSN ordered
> ringbuffer of in-progress insertions, with the reservation being a single
> 64bit atomic increment, without the need for a low limit like
> NUM_XLOGINSERT_LOCKS (the ring size needs to be limited, but I didn't see a
> disadvantage with using something like MaxConnections * 2).

There is such attempt at [1]. And Zhiguo tells it really shows promising
results.

No, I did it not with "ring-buffer", but rather with hash-table. But it is
still lock-free.

But after implementing that I found WALBufMappingLock [2] (which is already
removed).

And then all stuck in WALWrite lock.

> However, I think there's somewhat of an *inverse* relationship.  To
> efficiently flush WAL in smaller increments, we need a cheap way of
> identifying the number of backends that need to wait up to a certain LSN.

I believe, LWLockWaitForVar should be redone:
- currently it waits for variable to change (ie to be disctinct from
provided value).
- but I believe, it should wait for variable to be greater than provided value.

This way:
- WALInsertLock waiter will not awake for every change of insertingAt
- process, which writes and fsync WAL, will be able to awake waiters on
every fsync, instead of end of whole write.

It will reduce overhead of waiting WALInsertLock a lot, and will greately
reduce time spend on waiting WALWrite lock.

Btw, insertingAt have to be filled at the start of copying wal record to
wal buffers. Yes, we believe copying of small wal record is fast, but when
a lot of wal inserters does their job, we needlessly sleep on their
WALInsertLock although they are already in the future.

[1] https://commitfest.postgresql.org/patch/5633/
[2] https://commitfest.postgresql.org/patch/5511/

-- 
regards
Yura Sokolov aka funny-falcon

view thread (8+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  Subject: Re: many sessions wait on LWlock WALWrite suddenly
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox