Thread: Some spinlock patch tests
I was testing the spinlock patches that Tom Lane posted last month on a quad opteron system running Suse 9.2 for x86_64. The test sql and database was from a real application of ours and I was interested in seeing what effect the patches might have. The database is entirely RAM resident and nothing else was running while I ran the tests. The results are puzzling (to me anyway). There was a big boost in performance when the concurrency level was less than or equal to 4 and a much smaller boost when the concurrency level was greater than 3. The puzzling part was the context switches though. Why the big falloff above 5? In any case these results explain some performance meltdowns we have been seeing. When the concurrency goes above 5 the performance falls off so rapidly that we would be better running serially on a single processor and the system has a hard time recovering. with patch N time cs from vmstat 1 37 50-100 2 49 70k-80k 4 79 290k-300k 5 183 6k-10k 8 299 4k-6k without patch N time cs from vmstat 1 36 50-100 2 53 55k-60k 4 185 45k-55k 5 218 7k-10k 8 315 4k-6k
Emil Briggs <emil@baymountain.com> writes: > I was testing the spinlock patches that Tom Lane posted last month > on a quad opteron system running Suse 9.2 for x86_64. Exactly which patch is this, and against what base version of Postgres? Also, what's the hardware (no, "x86_64" isn't specific enough)? regards, tom lane
> Emil Briggs <emil@baymountain.com> writes: > > I was testing the spinlock patches that Tom Lane posted last month > > on a quad opteron system running Suse 9.2 for x86_64. > > Exactly which patch is this, and against what base version of Postgres? > Also, what's the hardware (no, "x86_64" isn't specific enough)? > It's the patch referenced here http://archives.postgresql.org/pgsql-hackers/2005-09/msg00566.php from the thread titled "Spinlocks, yet again: analysis and proposed patches" I applied all the pieces of the patch against v8.0.4. The hardware is a Celestica A8440 with 4 2Ghz Opterons and 16Gbytes of RAM.