--- In firebird-support@yahoogroups.com, "Ann W. Harrison"
<aharrison@...> wrote:

> There's some code in ... in ... in... the configuration code that
> checks that parameters are rational. The code was rewritten for
> V2.0 and separately rewritten for Vulcan, but the files are all
> called config. Each of them has a separate and confusing set of
> of conventions that made great sense to the authors.

Actually, it's not in the config code: you can set any integer there
that you want. But init_lock_table() in src/lock/lock.cpp tests
against the macros defined there:


if (LOCK_hash_slots < HASH_MIN_SLOTS)
LOCK_hash_slots = HASH_MIN_SLOTS;
if (LOCK_hash_slots > HASH_MAX_SLOTS)
LOCK_hash_slots = HASH_MAX_SLOTS;

If I were doing this, I'd probably set the HASH_MAX_SLOTS to 32767:
even though it's an unsigned short, I never trust that sign extension
will work right, so I stick with the limit of a *signed* variable.

If I can get the vendor to tell me how he built his UDFs, I may be
able to play with this some and see if it cuts down on mutex waits.

The application has one particular customer whose processing takes an
extra long time, so I've captured a copy of that database before the
big weekly run, and can try this on a test machine. I'll restore the
file, turn a knob, reset the lock manager, run the process, and
measure the time and resources. Change another knob, do it again.
Lather, rinse, repeat.

Hopefully this will let us get a handle on which knobs matter.

Steve

---
Steve Friedl | UNIX Wizard | Microsoft MVP | www.unixwiz.net