Hey,
>>
>>
>
>A long while back, I came up with an idea that I think might help this out
>quite a bit. I suggested the notion of an "operation count" that is stored
>in each trail object. Every time we hit BDB, we do that within the context
>of a trail. If we simply increment an opcount for each operation, and then
>discover that certain things would create an opcount of 5000, then we know
>we've got some investigation.
>
>The fewer BDB operations per trail, then the smaller the locks. Generally.
>It is at least a start to find the problematic areas.
>
>Does that seem reasonable? Or am I missing something, and this wouldn't
>actually help much?
>
>
I'm very much in favor of statistics and logging features. I mention
adding a logging feature in my "still to be released" document. Man I
sound like a broken record. I'm *way* sorry about the delay.
Currently, with little effort at all, print_fs_stats or a "locking only
version" of it could be called upon entry and exit of suspect methods.
As an aside: making transactions smaller only helps when they are
artificially large. IOW, if making transactions smaller merely pushes
more conflict responsibility to us, we get nowhere. Access patterns
have to be understood to make real progress. Explicit locking
mechanisms, predictable access patterns, and schema changes will yield
the biggest wins IMO.
gat
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 21 06:11:36 2003