On Tue, Dec 7, 2010 at 1:10 AM, Robert Haas <robertmhaas@xxxxxxxxx> wrote: > On Sun, Nov 21, 2010 at 7:15 PM, Ivan Voras <ivoras@xxxxxxxxxxx> wrote: >> The "sbwait" part is from FreeBSD - IPC sockets, but so much blocking on >> semwait indicates large contention in PostgreSQL. > > I can reproduce this. I suspect, but cannot yet prove, that this is > contention over the lock manager partition locks or the buffer mapping > locks. > > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > > -- > Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-performance > Hi Robert, That's exactly what I concluded when I was doing the sysbench simple read-only test. I had also tried with different lock partitions and it did not help since they all go after the same table. I think one way to kind of avoid the problem on the same table is to do more granular locking (Maybe at page level instead of table level). But then I dont really understand on how to even create a prototype related to this one. If you can help create a prototype then I can test it out with my setup and see if it helps us to catch up with other guys out there. Also on the subject whether this is a real workload: in fact it seems all social networks uses this frequently with their usertables and this test actually came from my talks with Mark Callaghan which he says is very common in their environment where thousands of users pull up their userprofile data from the same table. Which is why I got interested in trying it more. Regards, Jignesh -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
