From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Kevin Grittner <kgrittn(at)gmail(dot)com> |
Cc: | Kevin Grittner <kgrittn(at)postgresql(dot)org>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, "pgsql-committers(at)postgresql(dot)org" <pgsql-committers(at)postgresql(dot)org> |
Subject: | Re: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold < |
Date: | 2016-04-12 19:28:01 |
Message-ID: | 20160412192801.wffn2vjyszyw4qa4@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
Hi,
On 2016-04-12 14:17:12 -0500, Kevin Grittner wrote:
> Well, something is different between your environment and mine,
> since I saw no difference at scale 100 and 2.2% at scale 200.
In a readonly test or r/w? A lot of this will be different between
single-socket and multi-socket servers; as soon as you have the latter
the likelihood of contention being bad goes up dramatically.
> So,
> knowing more about your hardware, OS, configuration, etc., might
> allow me to duplicate a problem so I can fix
> For example, I used a "real" pg config, like I would for a production
> machine (because that seems to me to be the environment that is most
> important): the kernel is 3.13 (not one with pessimal scheduling) and
> has tuning for THP, the deadline scheduler, the vm.*dirty* settings,
> etc. Without knowing even the kernel and what tuning the OS and pg
> have had on your box, I could take a lot of shots in the dark without
> hitting anything.
That shouldn't really matter much for a read-only, shared_buffer
resident, test? There's no IO and THP pretty much plays no role because
there's very few memory allocations (removing the pressure causing the
well known degradations).
> Oh, and the output of `numactl --hardware` would be good to have.
> Thanks for all information you can provide.
That was on Alexander's/PgPro's machine. Numactl wasn't installed, and I
didn't have root. But it has four numa domains (gathered via /sys/).
> It was the only reported case to that point, so the additional data
> point is valuable, if I can tell where that point is. And you
> don't have any evidence that even with your configuration that any
> performance regression remains for those who have the default value
> for old_snapshot_threshold?
I haven't tested yet.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2016-04-12 19:37:08 | pgsql: Remove unused function GetOldestWALSendPointer from walsender co |
Previous Message | Tom Lane | 2016-04-12 19:23:23 | pgsql: Redefine create_upper_paths_hook as being invoked once per upper |
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2016-04-12 19:37:49 | Re: Remove unused function from walsender.c |
Previous Message | Tom Lane | 2016-04-12 19:26:22 | Re: WIP: Upper planner pathification |