On 28/08/18 03:39, Daniel Wood wrote:
Having quit Amazon, where I was doing Postgres development, I've
started looking at various things I might work on for fun. One
thought is to start with something easy like the scalability of
GetSnapshotData(). :-)
Cool! :-)
I recently found it interesting to examine performance while running
near 1 million pgbench selects per sec on a 48 core/96 HT Skylake
box. I noticed that additional sessions trying to connect were timing
out when they got stuck in ProcArrayAdd trying to get the
ProcArrayLock in EXCLUSIVE mode. FYI, scale 1 with 2048 clients.
The question is whether it is possible that the problem with
GetSnapshotData() has reached a critical point, with respect to
snapshot scaling, on the newest high end systems.
Yeah, GetSnapshotData() certainly becomes a bottleneck in certain workloads.
What I'd like is a short cut to any of the current discussions of
various ideas to improve snapshot scaling. I have some of my own
ideas but want to review things before posting them.
The main solution we've been discussing on -hackers over the last few
years is changing the way snapshots work, to use a Commit Sequence
Number. If we assign each transaction an CSN, then a snapshot is just a
single integer, and GetSnapshotData() just needs to read the current
value of the CSN counter. CSNs have problems of their own, of course
:-). If you search the archives for "CSN", you'll find several threads
on that.
Other less invasive ideas have also been thrown around. For example,
when one backend acquires a snapshot, it could store a copy of that in
shared memory. The next call to GetSnapshotData() could then just
memcpy() the cached snapshot. Transaction commit would need to
invalidate the cached copy. This helps, if you have a lot reads and few
writes.
- Heikki
