Hi all,

We are running version SO-V1.0.0.796 (32 bitClassic)of Firebird on
Solaris 5.8 (64 bit) on a 4 processor Sun Sparc box. We have some
hundreds of users but only 20 - 40 at any one time. Occaisonally it
goes up to 70 odd). During the day when the users are active, the
apps typically connect, do a small amount of work, and disconnect.
Things run very well.

LOCK_MEM_SIZE is 983040 (10 times default) and LOCK_HASH_SLOTS is
513. Page size is 4096, and page buffers are set to 500 pages (2Mb).
The system has 4Gb of memory and suitably large swap (8Gb).

(I set LOCK_MEM_SIZE , V4_LOCK_MEM_SIZE and ANY_LOCK_MEM_SIZE just
to be sure :-) )

During the day, the gds_inet_servers use around 10Mb each.

At night though, we have a number of cron jobs that do a lot more
work. We have a number of GPRE type apps that run, extracting data
for various reports. As well as that gbak runs to back up the 3
databases, and we have another GPRE job that connects to each of 76
remote databases and fetches some data. I run this job in batches of
16 at a time because of bandwidth constraints. Each instance connects
to one remote database and to the va_access.gdb mentioned below in
the interbase.log extract.

The databases are fairly large, between 2 and 4Gb, split into 1Gb
files.

Lately, in the mornings, we find that things are not quite as we
expect. Typically the backups have completed, but some of the cron
jobs have not, and they are consuming ~100Mb of memory each. As well,
the users have started connecting, and some of their gds_inet_servers
are sitting at 100Mb each too. The system runs out of real memory,
starts swapping like crazy, and things are real slow.

gds_lock_print reports around 40% mutex waits, lock header block
around 6000000, hash lengths of about 100 or so.

During nominal operation, those values are about 10%, 2000000, and 10
respectively.

If we then kill every single process that is accessing the databases,
everything returns to normal.

Previously we had run IB5.5 (Superserver). Besides not taking
advantage of the multiple processors, all jobs ran as expected, but
much slower of course.

The interbase.log always reports the following errors:

sun-1 Sun May 5 03:03:45 2002
INET/inet_error: connect errno = 145

sun-1 Sun May 5 03:03:45 2002
INET/inet_error: connect errno = 128

sun-1 Sun May 5 03:03:55 2002
Database: /db/va_access.gdb
page 374182, page type 5 lock conversion denied (215)

sun-1 Sun May 5 03:07:31 2002
INET/inet_error: connect errno = 145

sun-1 Sun May 5 03:07:32 2002
INET/inet_error: connect errno = 128

sun-1 Sun May 5 03:09:05 2002
Database: /db/va_access.gdb
page 373809, page type 4 lock conversion denied (215)

sun-1 Sun May 5 04:26:19 2002
INET/inet_error: read errno = 131


Questions:

1. Is there any way to limit the size of an Interbase process?
SOmetimes when we run a single GPRE data extract, the process grows
to 100Mb, even though the extract is very simple.

2. Are there some tunable parameters which would make a difference?

3. I have just realised that my setting of 983040 for LOCK_MEM_SIZE
is pretty low compared to what the engine is actually using (between
2 and 6Mb). This block does grow as required, but is there a
performance hit associated with this? e.g. if the lock memory is
fragmented into small blocks?

4. What are these lock conversion errors? How do we avoid them?

Any other suggestions?

Thanks in advance...

Vince