Simon,
> Clearly, OSDL-DBT2 is not a real world test! That is its benefit, since
> it is heavily instrumented and we are able to re-run it many times
> without different parameter settings. The application is well known and
> doesn't suffer that badly from factors that would allow certain effects
> to be swamped. If it had too much randomness or variation, it would be
> difficult to interpret.
I don't think you followed me. The issue is that for parameters designed to
"smooth out spikes" like bgwriter and vacuum delay, it helps to have really
bad spikes to begin with. There's a possibility that the parameters (and
calculations) that work well for for a "steady-state" OLTP application are
actually bad for an application with much more erratic usage, just as a high
sort_mem is good for DSS and bad for OLTP.
> Mark's efforts to
> improve the instrumentation of the tests will be useful on other
> workloads also.
Yep, it's been a lot of help. Heck, this is the first time we've had
parameters based on planned tests and not just anecdotes. That's a huge step
forward.
I'm just suggesting that we can improve the test still further specifically
for testing things like bgwriter.
> I'd encourage you to develop variations of DBT2 that can also be used to
> tune the server, hopefully running on OSDL. I support open testing
> methods as much as I support open development methods and projects.
Yeah, I'll just have to do it in a different programming language ;-b
>
> DBT3 next...
Yes, I started setting up a 200GB DBT3 database on one of OSDL's machines.
You're welcome to it, I don't see myself completeting those tests before the
holidays. Want login?
--Josh
--
__Aglio Database Solutions_______________
Josh Berkus Consultant
josh@agliodbs.com www.agliodbs.com
Ph: 415-752-2500 Fax: 415-752-2387
2166 Hayes Suite 200 San Francisco, CA
