Re: Load Distributed Checkpoints test results

From: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
To: Greg Smith <gsmith(at)gregsmith(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Load Distributed Checkpoints test results
Date: 2007-06-20 20:55:34
Message-ID: 46799446.60301@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greg Smith wrote:
> While it shows up in the 90% figure, what happens is most obvious in the
> response time distribution graphs. Someone who is currently getting a
> run like #295 right now: http://community.enterprisedb.com/ldc/295/rt.html
>
> Might be really unhappy if they turn on LDC expecting to smooth out
> checkpoints and get the shift of #296 instead:
> http://community.enterprisedb.com/ldc/296/rt.html

You mean the shift and "flattening" of the graph to the right in the
delivery response time distribution graph? Looking at the other runs,
that graph looks sufficiently different between the two baseline runs
and the patched runs that I really wouldn't draw any conclusion from that.

In any case you *can* disable LDC if you want to.

> That is of course cherry-picking the most extreme examples. But it
> illustrates my concern about the possibility for LDC making things worse
> on a really overloaded system, which is kind of counter-intuitive
> because you might expect that would be the best case for its improvements.

Well, it is indeed cherry-picking, so I still don't see how LDC could
make things worse on a really overloaded system. I grant you there might
indeed be one, but I'd like to understand the underlaying mechanism, or
at least see one.

> Since there is so much variability in results
> when you get into this territory, you really need to run a lot of these
> tests to get a feel for the spread of behavior.

I think that's the real lesson from this. In any case, at least LDC
doesn't seem to hurt much in any of the test configurations tested this
far, and smooths the checkpoints a lot in most configurations.

> I spent about a week of
> continuously running tests stalking this bugger before I felt I'd mapped
> out the boundaries with my app. You've got your own priorities, but I'd
> suggest you try to find enough time for a more exhaustive look at this
> area before nailing down the final form for the patch.

I don't have any good simple ideas on how to make it better in 8.3
timeframe, so I don't think there's much to learn from repeating these
tests.

That said, running tests is easy and doesn't take much effort. If you
have suggestions for configurations or workloads to test, I'll be happy
to do that.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua D. Drake 2007-06-20 21:00:40 Re: Load Distributed Checkpoints test results
Previous Message Oleg Bartunov 2007-06-20 20:44:53 Re: Updated tsearch documentation