Thread: performance results on IBM POWER7

IBM has provided the PostgreSQL community with access to a couple of
IBM POWER7 machines through OSUOSL.  Simon has access to one, carved
up into a couple of LPARs, for replication work, and there's a
buildfarm animal on there as well, I think; I have access to the
other, for performance testing.  I imagine we can get access for a few
other people as well, though at the moment the performance-testing
machine is inaccessible and I'm not having very much luck getting help
from the very busy OSUOSL folks.  Anyway, before it bit the dust, I
was able to do some basic pgbench tests at various scale factors and
client counts.  I used my usual settings:

shared_buffers = 8GB
maintenance_work_mem = 1GB
synchronous_commit = off
checkpoint_segments = 300
checkpoint_timeout = 15min
checkpoint_completion_target = 0.9
wal_writer_delay = 20ms

I did three five-minute runs at each scale factors 100, 300, 1000,
3000, and 10000, with varying client counts: 1, 2, and all multiples
of 4 up to 80.  I stopped and restarted the database after each run
(but did not flush the OS cache, so this is a warm-start test) and
took the median of the three results for each run.  Full results are
attached herewith; pretty graphs are on my blog at
http://rhaas.blogspot.com/2012/03/performance-and-scalability-on-ibm.html

When I get the machine back, my plan is to next run some read-write
pgbench tests.  Those will need to be longer, though.  Read
performance doesn't seem to be very sensitive to the length of the
tests, but write performance is, so I'll probably need at least
30-minute runs if not more to get an accurate sense of what the
performance is like.  After that I think maybe some testing of the
remaining CommitFest patches might be in order (though personally I'd
like to wrap this CommitFest up fairly soon) to see if any of those
improve things.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Thu, Mar 1, 2012 at 4:54 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> ... After that I think maybe some testing of the
> remaining CommitFest patches might be in order (though personally I'd
> like to wrap this CommitFest up fairly soon) to see if any of those
> improve things.

Besides performance testing, could you check how clocksources behave
on this kind of machine?
You can find pg_test_timing tool attached here:
http://archives.postgresql.org/pgsql-hackers/2012-01/msg00937.php

To see which clocksources are available, you can do:
# cat /sys/devices/system/clocksource/clocksource0/available_clocksource
To switch the clocksource, just write the desired clocksource like this:
# echo hpet > /sys/devices/system/clocksource/clocksource0/current_clocksource

Thanks,
Ants Aasma

On Thu, Mar 1, 2012 at 11:23 AM, Ants Aasma <ants.aasma@eesti.ee> wrote:
> On Thu, Mar 1, 2012 at 4:54 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> ... After that I think maybe some testing of the
>> remaining CommitFest patches might be in order (though personally I'd
>> like to wrap this CommitFest up fairly soon) to see if any of those
>> improve things.
>
> Besides performance testing, could you check how clocksources behave
> on this kind of machine?
> You can find pg_test_timing tool attached here:
> http://archives.postgresql.org/pgsql-hackers/2012-01/msg00937.php
>
> To see which clocksources are available, you can do:
> # cat /sys/devices/system/clocksource/clocksource0/available_clocksource
> To switch the clocksource, just write the desired clocksource like this:
> # echo hpet > /sys/devices/system/clocksource/clocksource0/current_clocksource

Sure, I'll check that as soon as it's back up.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Thu, Mar 1, 2012 at 11:38 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Thu, Mar 1, 2012 at 11:23 AM, Ants Aasma <ants.aasma@eesti.ee> wrote:
>> On Thu, Mar 1, 2012 at 4:54 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>>> ... After that I think maybe some testing of the
>>> remaining CommitFest patches might be in order (though personally I'd
>>> like to wrap this CommitFest up fairly soon) to see if any of those
>>> improve things.
>>
>> Besides performance testing, could you check how clocksources behave
>> on this kind of machine?
>> You can find pg_test_timing tool attached here:
>> http://archives.postgresql.org/pgsql-hackers/2012-01/msg00937.php
>>
>> To see which clocksources are available, you can do:
>> # cat /sys/devices/system/clocksource/clocksource0/available_clocksource
>> To switch the clocksource, just write the desired clocksource like this:
>> # echo hpet > /sys/devices/system/clocksource/clocksource0/current_clocksource
>
> Sure, I'll check that as soon as it's back up.

It seems that "timebase" is the only available clock source.
pg_test_timing says:

Testing timing overhead for 3 seconds.
Per timing duration including loop overhead: 38.47 ns
Histogram of timing durations:  < usec:      count   percent      32:          6  0.00001%      16:          4
0.00001%      8:          8  0.00001%       4:        282  0.00036%       2:    2999189  3.84628%       1:   74976816
96.15333%

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company