Re: kernel lock contention and scalability

[Jonathan Lahr]

> Tridge and I tried out the postgresql benchmark you used here and this
> contention is due to a bug in postgres. From a quick strace, we found
> the threads do a load of select(0, NULL, NULL, NULL, {0,0}). Basically all
> threads are pounding on schedule().
...
> Our guess is that the app has some form of userspace synchronisation
> (semaphores/spinlocks). I'd argue that the app needs to be fixed not the
> kernel, or a more valid test case is put forwards. :)
...
> PS: I just looked at the postgresql source and the spinlocks (s_lock() etc)
> are in a tight loop doing select(0, NULL, NULL, NULL, {0,0}). 

Anton,

Thanks for looking into postgresql/pgbench related locking.  Yes, 
apparently postgresql uses a synchronization scheme that uses select()
to effect delays for backing off while attempting to acquire a lock.
However, it seems to me that runqueue lock contention was not entirely due 
to postgresql code, since it was largely alleviated by the multiqueue 
scheduler patch.

In using postgresql/pgbench to measure lock contention, I was attempting
to apply a typical server workload to measure scalability using only open 
software.  My goal is to load and measure the kernel for server performance, 
so I need to ensure that the software I use represents likely real world 
server configurations.  I did not use mysql, because it cannot perform 
transactions which I considered important.  Any pointers to other open 
database software or benchmarks that might be suitable for this effort 
would be appreciated.

Jonathan