On 2013-09-27 09:57:07 +0200, Andres Freund wrote: > On 2013-09-27 09:21:05 +0200, Andres Freund wrote: > > > >So the goal is to have LWLockAcquire(LW_SHARED) never block unless > > > >somebody else holds an exclusive lock. To produce enough appetite for > > > >reading the rest of the long mail, here's some numbers on a > > > >pgbench -j 90 -c 90 -T 60 -S (-i -s 10) on a 4xE5-4620 > > > > > > > >master + padding: tps = 146904.451764 > > > >master + padding + lwlock: tps = 590445.927065 > > > > > > How does that compare with simply increasing NUM_BUFFER_PARTITIONS? > > > > Heaps better. In the case causing this investigation lots of the pages > > with hot spinlocks were the simply the same ones over and over again, > > partitioning the lockspace won't help much there. > > That's not exactly an uncommon scenario since often enough there's a > > small amount of data hit very frequently and lots more that is accessed > > only infrequently. E.g. recently inserted data and such tends to be very > > hot. > > > > I can run a test on the 4 socket machine if it's unused, but on my 2 > > socket workstation the benefits of at least our simulation of the > > original workloads the improvements were marginal after increasing the > > padding to a full cacheline. > > Ok, was free: > > padding + 16 partitions: > tps = 147884.648416 > > padding + 32 partitions: > tps = 141777.841125 > > padding + 64 partitions: > tps = 141561.539790 > > padding + 16 partitions + new lwlocks > tps = 601895.580903 (yeha, still reproduces after some sleep!)
Pgbench numbers for writes on the machine (fsync = off, synchronous_commit = off): padding + 16 partitions: tps = 8903.532163 vs padding + 16 partitions + new lwlocks tps = 13324.080491 So, on bigger machines the advantages seem to be there for writes as well... Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers