On Fri, 15 Jun 2007, Gregory Stark wrote:
> If I understand it right Greg Smith's concern is that in a busier system
> where even *with* the load distributed checkpoint the i/o bandwidth
> demand during t he checkpoint was *still* being pushed over 100% then
> spreading out the load would only exacerbate the problem by extending
> the outage.
Thank you for that very concise summary; that's exactly what I've run
into. DBT2 creates a heavy write load, but it's not testing a real burst
behavior where something is writing as fast as it's possible to.
I've been involved in applications that are more like a data logging
situation, where periodically you get some data source tossing
transactions in as fast as it will hit disk--the upstream source
temporarily becomes faster at generating data during these periods than
the database itself can be. Under normal conditions, the LDC smoothing
would be a win, as it would lower the number of times the entire flow of
operations got stuck. But at these peaks it will, as you say, extend the
outage.
> It might even make sense to run a test with an outright overloaded to
> see if the patch doesn't exacerbate the condition.
Exactly. I expect that it will make things worse, but I'd like to keep an
eye on making sure the knobs are available so that it's only slightly
worse.
I think it's important to at least recognize that someone who wants LDC
normally might occasionally have a period where they're completely
overloaded, and that this new feature doesn't have an unexpected breakdown
when that happens. I'm still stuggling with creating a simple test case
to demonstrate what I'm concerned about. I'm not familiar enough with the
TPC testing to say whether your suggestions for adjusting warehouse size
would accomplish that (because the flow is so different I had to abandon
working with that a while ago as not being representative of what I was
doing), but I'm glad you're thinking about it.
--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD