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
