Re: track_planning causing performance regression
Fujii Masao <masao.fujii@oss.nttdata.com>
From: Fujii Masao <masao.fujii@oss.nttdata.com>
To: Ants Aasma <ants@cybertec.at>
Cc: Julien Rouhaud <rjuju123@gmail.com>, "Tharakan, Robins"
<tharar@amazon.com>,
"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2020-06-30T13:40:09Z
Lists: pgsql-hackers
On 2020/06/30 20:30, Ants Aasma wrote: > On Tue, 30 Jun 2020 at 08:43, Fujii Masao <masao.fujii@oss.nttdata.com <mailto:masao.fujii@oss.nttdata.com>> wrote: > > > The problem looks to be that spinlocks are terrible with overloaded CPU and a contended spinlock. A process holding the spinlock might easily get scheduled out leading to excessive spinning by everybody. I think a simple thing to try would be to replace the spinlock with LWLock. > > Yes. Attached is the POC patch that replaces per-counter spinlock with LWLock. > > > Great. I think this is the one that should get considered for testing. > > > I did a prototype patch that replaces spinlocks with futexes, but was not able to find a workload where it mattered. > > I'm not familiar with futex, but could you tell me why you used futex instead > of LWLock that we already have? Is futex portable? > > > Futex is a Linux kernel call that allows to build a lock that has uncontended cases work fully in user space almost exactly like a spinlock, while falling back to syscalls that wait for wakeup in case of contention. It's not portable, but probably something similar could be implemented for other operating systems. I did not pursue this further because it became apparent that every performance critical spinlock had already been removed. > > To be clear, I am not advocating for this patch to get included. I just had the patch immediately available and it could have confirmed that using a better lock fixes things. Understood. Thanks for the explanation! Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
Commits
-
doc: Fix description about pg_stat_statements.track_planning.
- 306c5e05e20f 13.4 landed
- e48f2afee631 14.0 landed
- 9d2a7757347c 15.0 landed
-
doc: Add note about possible performance overhead by enabling track_planning.
- da6b6ff95bca 13.0 landed
- 321fa6a4a26c 14.0 landed
-
Change default of pg_stat_statements.track_planning to off.
- 8d459762b103 13.0 landed
- d1763ea8c9c3 14.0 landed