SMP Read-only Performance - Mailing list pgsql-general

From Mike Bresnahan
Subject SMP Read-only Performance
Date
Msg-id loom.20100126T230042-903@post.gmane.org
Whole thread Raw
Responses Re: SMP Read-only Performance  (Scott Marlowe <scott.marlowe@gmail.com>)
Re: SMP Read-only Performance  (Greg Smith <greg@2ndquadrant.com>)
List pgsql-general
I have a read-only database that I am testing the performance of to get a sense
of how many concurrent users I can support. The database fits entirely in RAM so
I expect there to be little to no disk activity. Because of this, I expect
throughput to scale almost linearly with the number of CPUs I have. However,
that is not what I am seeing. For example, take the following results.

Postgres 8.3.8
Fedora 9
Intel(R) Xeon(R) CPU 5160 @ 3.00GHz X 2 (4 cores total)
4 GB RAM

-bash-3.2$ pgbench -c 1 -S -t 400000 test
starting vacuum...end.
transaction type: SELECT only
scaling factor: 64
number of clients: 1
number of transactions per client: 400000
number of transactions actually processed: 400000/400000
tps = 11373.127109 (including connections establishing)
tps = 11373.907131 (excluding connections establishing)

-bash-3.2$ pgbench -c 2 -S -t 200000 test
starting vacuum...end.
transaction type: SELECT only
scaling factor: 64
number of clients: 2
number of transactions per client: 200000
number of transactions actually processed: 400000/400000
tps = 11422.541958 (including connections establishing)
tps = 11423.979642 (excluding connections establishing)

-bash-3.2$ pgbench -c 3 -S -t 200000 test
starting vacuum...end.
transaction type: SELECT only
scaling factor: 64
number of clients: 3
number of transactions per client: 200000
number of transactions actually processed: 600000/600000
tps = 11330.641664 (including connections establishing)
tps = 11332.074176 (excluding connections establishing)

-bash-3.2$ pgbench -c 4 -S -t 100000 test
starting vacuum...end.
transaction type: SELECT only
scaling factor: 64
number of clients: 4
number of transactions per client: 100000
number of transactions actually processed: 400000/400000
tps = 11747.647262 (including connections establishing)
tps = 11750.710786 (excluding connections establishing)

During these tests top(1) reported 60-70% idle CPU.

As you see, the TPS remains the same as I increase the number of clients. These
results make it look like PostgreSQL is single-threaded and not taking advantage
of the multiple cores. Could someone please explain?






pgsql-general by date:

Previous
From: Greg Smith
Date:
Subject: Re: Postgres Host
Next
From: Craig Ringer
Date:
Subject: Re: create role in a pl/pgsql trigger