Poor PostgreSQL scaling on Linux 2.6.25-rc5 (vs 2.6.22)

[Nick Piggin]

Hi,

After investigating the claims of poor MySQL performance on Linux,
I had a look at postgresql with sysbench. This DBMS is even faster
than MySQL and could scale up to more connections with my (as close
as possible) out of the box compile and config. The nice thing
about PostgreSQL is that it has no noticable contention on user
space locks on this workload.

The problem with MySQL contention means that if the scheduler
unluckily chooses to deschedule a lock holder, then you can get
idle time building up on other cores and you can get context switch
cascades as things all pile up onto this heavily contended lock. As
such, it means MySQL is not an ideal candidate for looking at
performance behaviour. I discounted the relatively worse scaling of
MySQL with 2.6.25-rc (than 2.6.22) as such an effect.

PostgreSQL is different. It has zero idle time when running this
workload. It actually scaled "super linearly" on my system here,
from single threaded performance to 8 cores (giving an 8.2x
performance increase)!

So PostgreSQL performance profile is actually much more interesting.
To my dismay, I found that Linux 2.6.25-rc5 performs really badly
after saturating the runqueues and subsequently increasing threads.
2.6.22 drops a little bit, but basically settles near the peak
performance. With 2.6.25-rc5, throughput seems to be falling off
linearly with the number of threads.

Actually, this performance profile sort of matches the MySQL curve,
so while I thought the MySQL numbers may be invalid, actually it
appears to back up the pgsql numbers.

This was with postgresql 8.3; config and kernel config available on
request. Looks very much like a CPU scheduler issue. Please take a
look.

postgres.png contains 2.6.22 vs 2.6.25-rc5. compare.png contains
both of those plus MySQL on 2.6.22 vs 2.6.25-rc5.

Thanks,
Nick

Attachment: postgres.png
Description: PNG image

Attachment: compare.png
Description: PNG image