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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <200803111749.29143.nickpiggin@yahoo.com.au>
Date:	Tue, 11 Mar 2008 17:49:28 +1100
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	"Molnar, Ingo" <mingo@...e.hu>, LKML <linux-kernel@...r.kernel.org>
Subject: Poor PostgreSQL scaling on Linux 2.6.25-rc5 (vs 2.6.22)

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

Download attachment "postgres.png" of type "image/png" (3966 bytes)

Download attachment "compare.png" of type "image/png" (5115 bytes)