Re: [Testperf-general] Re: 8.0beta5 results w/ dbt2

On Mon, Dec 06, 2004 at 09:28:15PM +0000, Simon Riggs wrote:
> Mark,
> 
> Few questions:
> 
> - can we put the logging to DEBUG1 please, so we can see the
> checkpoints? ...and set debug_shared_buffers = 10

Ok, will do.

> I don't understand why the checkpoints are so regular at 300 seconds if
> the checkpoint_timeout is set to 1800 or other...exactly when and how
> are those parameters provided to the server?

I don't think I do either.  I always set the parameters by editing the
postgresql.conf file.

> - can we set checkpoint_segments to 8192 just to see if that changes the
> checkpoint frequency (it should)

Ok.

> - the log output shows the database starts about 4 hours before the main
> test starts... err whats going on there? maybe we could get more tests
> in if that time could be reduced

I start 5000 clients every 3 seconds.  I tend to find if I start them
too fast, my client tends to start dropping connections.  Maybe a
tcp/ip tuning problem between my client and driver.

> - the explain plan output is missing...
> http://www.osdl.org/projects/dbt2dev/results/dev4-010/199/db/plan0.out.gz

Ugh, I really do mean to fix that...  Something changed so it's not
being captured at all.  It really should be easy for me to fix.

> - the log output shows deadlocks occurring - is there something about
> the application of DBT-2 which is actually causing contention? Might
> that have changed between beta4 and beta5? The earlier lock waits we saw
> ("Exclusive Lock" thread) are likely to be related to that. Is there
> some other artifact of the test that could cause this...random number
> generator....etc. My understanding was that TPC-C didn't deadlock, but I
> could be wrong there. This could easily be throwing off the test
> results... usually to do with the order in which locks are occurring...
> if its not, I hope its not a bug,,,

Nothing that I can think of.  Each thread is initialized with a
different random number seed so we shouldn't see any identicle
transactions occuring because of that.

Mark