LockHashSlots and LockMemSize

[Dany40]

Hello!

Is there any logic to set this parameters? In my case, Firebird 5.0.3 64bit server is running as SuperServer. It has 140 databases connected; the sizes are from 24 MB to 130 GB, and the connected users to each can be from 1 to 50, but all the databases together can have up to 300 users connected at the same time. The biggest table has a blob field in where with no more of 4mb in blob size, but this table can have 1 millon records. In most cases the size of each database is 80 or 90% from this blobs.

I am not sure what is the best combination for my case.

Thank you!

[Dimitry Sibiryakov]

Dany40 wrote 12.12.2025 17:30:
> Is there any logic to set this parameters?

The logic is simple: *do not touch them* unless fb_lock_print shows you big
number of hash collisions and big table growth respectively.

--
WBR, SD.

[Mark Rotteveel]

This not really a matter of "combination", they are pretty much separate
things.

Increase LockHashSlots to a higher prime if the "Hash lengths" in the
fb_lock_print output become very long (on average 20 or more is the
general advice).

In any case, LockMemSize is the initial allocation size, and the growth
increment if lock memory needs to grow. I'm not sure if there is a solid
advice to give on its sizing (though on the other hand, its default of
64 KiB is of course peanuts these days).

Mark
--
Mark Rotteveel

[Dany40]

Thank you. What confuses me about fb_lock_print is that I use a SuperServer for a total of 130 databases, and I understand that in that case the lock manager is a resource shared by all those databases; but to use this utility I have to specify which database I want to monitor. Does the printed result refer to that specific database or to the overall situation?

Thank you again.

[Dimitry Sibiryakov]

Dany40 wrote 17.12.2025 20:50:
> I use a SuperServer for a total of 130 databases, and I understand that in that
> case the lock manager is a resource shared by all those databases

No, it not. Every database has its own lock table.

--
WBR, SD.

[Dany40]

>>>No, it not. Every database has its own lock table.

If this is the case, it can be very very helpfull (if possible) to write on the firebird.log the database from where the error "Fatal lock manager error: Process disappeared in LockManager" is comming. 

Very very helpfull.

Regards!

[Dimitry Sibiryakov]

Dany40 wrote 17.12.2025 21:40:
> it can be very very helpfull (if possible) to write on the firebird.log the
> database from where the error "Fatal lock manager error: Process disappeared in
> LockManager" is comming.

What usage for this information do you have on mind?

--
WBR, SD.

[Dany40]

Now I am getting this fatal error on the firebird.log but I don't know which database is affected; sure it can help me to find the source of this problem. I am getting this error at least once every day. For example, I can do fb_lock_print for that database to get information that can help me.

[Dimitry Sibiryakov]

Dany40 wrote 17.12.2025 23:10:
> sure it can help me to find the source of this problem. I am getting this error
> at least once every day. For example, I can do fb_lock_print for that database
> to get information that can help me.

Say, you see that the problem is with security.fdb (most probable option).
What the next?

--
WBR, SD.

[Dany40]

If we can see that this error every day is comming from the context of the same database, do you really think it is not important to know that?

[Dimitry Sibiryakov]

Dany40 wrote 17.12.2025 23:37:
> If we can see that this error every day is comming from the context of the same
> database, do you really think it is not important to know that?

I don't know. I'm curious what you can do in this situation because I
personally have no idea how it is possible to handle such kind of error without
creation of an own custom Firebird build for trial-and-error experiments.

--
WBR, SD.

[Tommi Prami]

   I don't know. I'm curious what you can do in this situation because I
personally have no idea how it is possible to handle such kind of error without
creation of an own custom Firebird build for trial-and-error experiments.

Would think that if Firebird would log the information of the database, and error would be more than less deproducible. Then I could Fb to the programmer, to sturdy/debug.

Maybe not related to this particular case, or maybe is. But I really would like that every time there is an error, and it is logged, there would be also the database that was in use at the time of the error, if possible,

-tee-

[Dany40]

In my case, lots of databases are in use at the same time. I think it is very usefull to know in the context of what database that fatal error is.

[Dimitry Sibiryakov]

Dany40 wrote 18.12.2025 12:41:
> In my case, lots of databases are in use at the same time. I think it is very
> usefull to know in the context of what database that fatal error is.

In this case apply this simple patch:

-------------------- 8<-------------------
diff --git a/src/lock/lock.cpp b/src/lock/lock.cpp
index 59fab14dd6..2af341a32f 100644
--- a/src/lock/lock.cpp
+++ b/src/lock/lock.cpp
@@ -1068,7 +1068,7 @@ void LockManager::acquire_shmem(SRQ_PTR owner_offset)
{
fb_assert(!m_process);
if (m_process)
- bug(NULL, "Process disappeared in LockManager::acquire_shmem");
+ bug(NULL, "Process disappeared in LockManager::acquire_shmem (database id
%s)", m_dbId.c_str());

// Shared memory must be empty at this point
fb_assert(SRQ_EMPTY(m_sharedMemory->getHeader()->lhb_processes));

-------------------- >8 ------------------

It won't show you database name but its UUID (which is also used for lock
file name, which can be used for fb_lock_print command), but finding db by id
shouldn't be hard even if there are 300 of them.

--
WBR, SD.

[Vlad Khorsun]

Now I am getting this fatal error on the firebird.log but I don't know which database is affected; sure it can help me to find the source of this problem. I am getting this error at least once every day.

  Why you still not provide me with memory dump then ?

Regards,

Vlad

[Dany40]

Hi Vlad;

  When I tried to set up ProcDump, as soon as the servers started to receive significant load they began to go down in a chain, one after another, and our help desk was overwhelmed within minutes. I know you pointed out what the mistake was when setting up ProcDump, but I can’t take the risk of that situation happening again, at least for the time being. I can try again if you can clearly outline exactly what I should do. Thank you very much in advance for your help.

Regards

Dany