From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Subject: | perform_spin_delay() vs wait events |
Date: | 2022-11-20 20:43:10 |
Message-ID: | 20221120204310.xywrhyxyytsajuuq@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
The lwlock wait queue scalability issue [1] was quite hard to find because of
the exponential backoff and because we adjust spins_per_delay over time within
a backend.
I think the least we could do to make this easier would be to signal spin
delays as wait events. We surely don't want to do so for non-contended spins
because of the overhead, but once we get to the point of calling pg_usleep()
that's not an issue.
I don't think it's worth trying to hand down more detailed information about
the specific spinlock we're waiting on, at least for now. We'd have to invent
a whole lot of new wait events because most spinlocks don't have ones yet.
I couldn't quite decide what wait_event_type to best group this under? In the
attached patch I put it under timeouts, which doesn't seem awful.
I reverted a4adc31f690 and indeed it shows SpinDelay wait events before the
fix and not after.
Greetings,
Andres Freund
[1] https://postgr.es/m/20221027165914.2hofzp4cvutj6gin%40awork3.anarazel.de
Attachment | Content-Type | Size |
---|---|---|
0001-Add-WAIT_EVENT_SPIN_DELAY.patch | text/x-diff | 2.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2022-11-20 21:09:03 | Re: Unstable regression test for contrib/pageinspect |
Previous Message | Tom Lane | 2022-11-20 20:37:26 | Unstable regression test for contrib/pageinspect |