Re: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <

From: Kevin Grittner <kgrittn(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, Kevin Grittner <kgrittn(at)postgresql(dot)org>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <
Date: 2016-04-13 16:25:47
Message-ID: CACjxUsO_m7SX38VtS_P3emLWaimOqFP0cY6TeD7TWJfevV3Xig@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

On Wed, Apr 13, 2016 at 10:59 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:

>> but as an example, if I only see such regression on a Linux kernel
>> with version a version < 3.8 I am going to be less concerned about
>> getting something into 9.6, since IMO it is completely irresponsible
>> to run a NUMA machine with 4 or more nodes on an OS with a substandard
>> NUMA scheduler. I'm not sure when 3.8 became available, but according
>> to Wikipedia Version 3.10 of the Linux kernel was released in June
>> 2013, so it's not like you need to be on the bleeding edge to have a
>> decent scheduler.
>
> I don't think effect of adding a single spinlock (an exclusive lock!) in
> a hot path is likely to be hugely dependant on the kernel version.

My experience is that is easily can be. We had a customer who
could not scale beyond a certain point due to spinlock contention
on a single spinlock already present in stock pg. We tried lots of
config tweaks and a some custom patches to no avail. Then we had
them upgrade from RHEL 6.latest to RHEL 7.latest, and they could
scale much, much farther. No OS or pg config changes were made at
the same time. The difference is that they went from kernel
version kernel 2.6.32 to kernel version 3.10.0. The early version
3 kernels had a NUMA scheduler rewrite that was a disaster compared
to 2.6.32. They rewrote it again in 3.8, with dramatic effect.

> We've had such cases before, and felt the pain. E.g. the spinlock in the
> ProcArrayLock used to be a *HUGE* contention point, and it has pretty
> much the same acquisition pattern as this spinlock now.

It would be great to have improvements in such access patterns, no
doubt. I'll be happy if we get there. I don't have a problem
trying to contribute to the effort, either, if people think that
might actually be a net gain. But if we have a point where those
not using the new feature are unaffected, and the question is about
the range of workloads where the new feature will be helpful in
9.6, it doesn't seem to me to rise to the level of a bug or a
release blocker.

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Andres Freund 2016-04-13 17:19:55 Re: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <
Previous Message Andres Freund 2016-04-13 15:59:42 Re: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2016-04-13 16:48:24 Re: Pglogical questions and problems
Previous Message Andres Freund 2016-04-13 15:59:42 Re: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <