Re: track_planning causing performance regression

From: Ants Aasma <ants(at)cybertec(dot)at>
To: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
Cc: Julien Rouhaud <rjuju123(at)gmail(dot)com>, "Tharakan, Robins" <tharar(at)amazon(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: track_planning causing performance regression
Date: 2020-06-30 11:30:03
Message-ID: CANwKhkPUBcSBMwR1=dgGe-7cZriQ=Rge4j_xv5wHni+YM_CgSA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 30 Jun 2020 at 08:43, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)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.

--
Ants Aasma
Senior Database Engineerwww.cybertec-postgresql.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2020-06-30 11:50:14 Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions
Previous Message Peter Eisentraut 2020-06-30 11:21:37 Re: Use of "long" in incremental sort code