On Tue, Apr 12, 2016 at 1:56 PM, Andres Freund <and...@anarazel.de> wrote: > On 2016-04-12 13:44:00 -0500, Kevin Grittner wrote: >> On Tue, Apr 12, 2016 at 12:38 PM, Andres Freund <and...@anarazel.de> wrote: >>> On 2016-04-12 16:49:25 +0000, Kevin Grittner wrote: >>>> On a big NUMA machine with 1000 connections in saturation load >>>> there was a performance regression due to spinlock contention, for >>>> acquiring values which were never used. Just fill with dummy >>>> values if we're not going to use them. >>> >>> FWIW, I could see massive regressions with just 64 connections. >> >> With what settings? > > You mean pgbench or postgres? The former -M prepared -c 64 -j 64 -S. The > latter just a large enough shared buffers to contains the scale 300 > database, and adapted maintenance_work_mem. Nothing special.
Well, something is different between your environment and mine, since I saw no difference at scale 100 and 2.2% at scale 200. So, knowing more about your hardware, OS, configuration, etc., might allow me to duplicate a problem so I can fix it. 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. Oh, and the output of `numactl --hardware` would be good to have. Thanks for all information you can provide. >> With or without the patch to avoid the locks when off? > > Without. Your commit message made it sound like you need unrealistic or > at least unusual numbers of connections, and that's afaics not the case. 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? -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
