Hi,
Tom Lane schrieb:
> Robert Lor <[EMAIL PROTECTED]> writes:
>> I ran pgbench and fired up a DTrace script using the lwlock probes we've
>> added, and it looks like BufMappingLock is the most contended lock, but
>> CheckpointStartLocks are held for longer duration!
>
> Those numbers look a b
On Fri, Jul 21, 2006 at 12:56:56AM -0700, Robert Lor wrote:
> I ran pgbench and fired up a DTrace script using the lwlock probes we've
> added, and it looks like BufMappingLock is the most contended lock, but
> CheckpointStartLocks are held for longer duration!
Not terribly surprising given th
Arjen van der Meijden wrote:
First of all, this graph has no origin. Its a bit difficult to test with
less than one cpu.
Sure it does. I ran all the tests. They all took infinite time, and I got
zero results. And my results are 100% accurate and reliable. It's perfectly
valid data. :-)
C
On 22-6-2006 15:03, David Roussel wrote:
Sureky the 'perfect' line ought to be linear? If the performance was
perfectly linear, then the 'pages generated' ought to be G times the
number (virtual) processors, where G is the gradient of the graph. In
such a case the graph will go through the or
Arjen van der Meijden
wrote:
Here is a graph of our performance measured on PostgreSQL:
http://achelois.tweakers.net/~acm/pgsql-t2000/T2000-schaling-postgresql.png
...
The "perfect" line is based on the "Max" value for 1 core and then just
multiplied by the amount of cores to have
Jim Nasby wrote:
On Jun 16, 2006, at 12:01 PM, Josh Berkus wrote:
First thing as soon as I have a login, of course, is to set up a
Buildfarm
instance.
Keep in mind that buildfarm clients and benchmarking stuff don't
usually mix well.
On a fast machine like this a buildfarm run is
On 17-6-2006 1:24, Josh Berkus wrote:
Arjen,
I can already confirm very good scalability (with our workload) on
postgresql on that machine. We've been testing a 32thread/16G-version
and it shows near-linear scaling when enabling 1, 2, 4, 6 and 8 cores
(with all four threads enabled).
Keen.
Tom,
> 18% in s_lock is definitely bad :-(. Were you able to determine which
> LWLock(s) are accounting for the contention?
Gavin Sherry and Tom Daly (Sun) are currently working on identifying the
problem lock using DLWLOCK_STATS. Any luck, Gavin?
--
Josh Berkus
PostgreSQL @ Sun
San Francisc
Arjen,
> I can already confirm very good scalability (with our workload) on
> postgresql on that machine. We've been testing a 32thread/16G-version
> and it shows near-linear scaling when enabling 1, 2, 4, 6 and 8 cores
> (with all four threads enabled).
Keen. We're trying to keep the linear sc
