Wednesday, June 20, 2007

PostgreSQL 8.2.4 Scaling on Sun Fire T2000 with Solaris 10 11/06


As I move into my new role of working on Open Source Databases, I decided to do a "checkpoint" as they say in the PostgreSQL world. The idea is to "test-it-myself" of how PostgreSQL scales on Solaris.


Using a setup configuration consisting of Sun Enterprise T2000 (I still call it Sun Fire T2000 sometimes) provided by my well known team member, I decided to start with doing a small scalability test with PostgreSQL on Sun Fire T2000 server. I decided the best approach to do a scalability study is to start with only one core active on Sun Fire T2000 (other disabled via psradm) and measure postgreSQL with pre-defined criterias of load execution. If the executions pass the criterias, then I increase the load and carry out another tests till the number of cores start to saturate and the pre-defined criterias of doing load executions starts to fail. Thats when additional UltraSPARC T1 core on Sun Fire T2000s is turned on and the test is repeated till all cores are active and saturated.


With the test defined and the configurations set, I downloaded the latest PostgreSQL 8.2.4 source code and compiled it with the latest Sun Studio 12 compiler tools on Solaris 10 11/06 (all on Sun Fire T2000). With the newly generated binaries, Using my new favorite postgreSQL database layout option on Sun StorageTek 2540 and my tested postgresql.conf tunables, I initialized the database and created the schema for the OLTP workload.


Carrying out the test as planned and normalizing the throughput gathered from the series of test, I charted the throughput versus the number of cores acvite and compared it against what could mean a linear scaling.


Before looking at the chart, remember that each core on UltraSPARC T1 chip shows in Solaris as four virtual CPUs. With the numbering scheme on current T2000 servers are 0-3 virtual CPUs are fore core 1, 4-7 virtual CPUs are for core 2 and so on. (Somehow it did not made logical sense to activate partial threads on a core and hence in the tests that I did at any given time they are either active or inactive.) I had used psradm to turn on or off the virtual CPUs.


The resulting chart is as follows:





As you can observe PostgreSQL 8.2.4 on Solaris achieved more than 6.5X throughput on 8 cores (each core being set of 4 virtual CPU threads) as compared to throughput with a single core activated. Also I would like to add that at the 8 core run, the cpu on the driver machines were also nearing their peak value and could have caused some degradation on the 8 core test. (Since I also observed about 15-18% idle time with all cores active.) But still I think the results were beyond my expecations from what I expected of an Open Source Database. Why? Because even at this rate (of dropping scaling percentage), PostgreSQL 8.2.4 can scale well beyond 25-30 such cores or 100-120 virtual CPUs before the absolute throughput of PostgreSQL on UltraSPARC T1 cores is saturated.



3 comments:

Derek Morr said...

What benchmark were you using here? pgtest? something else?

Patrick Giagnocavo said...

Two questions 1: did you check to be sure that little to no FPU instructions were used in the PG tests? 2: Did you run up to 32 processes (1 per thread) or just up to 8 processes (1 per core)? Am curious what you tuned in the postgresql.conf. Also, did you try running Postgres data files in memfs - idle time you noticed could be due to iowait on disks maybe?

Thorleif Wiik said...

Can you publish the Sun Studio 12 Compiler flags and your postgresql.conf ?