Messages in this thread | | | Date | Tue, 6 Mar 2001 14:45:52 -0800 | From | Jonathan Lahr <> | Subject | Re: kernel lock contention and scalability |
| |
> 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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |