Hi,
The only thing I can say that situation is not obvious, I suggest to ask
for professional support:
https://www.firebirdsql.org/en/support/
Regards,
Alexey
Hi Alexey,
I have already changed the configuration, but it didn’t help. What I
find strange is the fact, that the memory consumption drops like it
would do when you close all connections. See my first description of
the problem. And only to be clear when I say hang, basically it locks
up without any sign of processing. When does Firebird perform deadlock
scans? We have a lot of things going on and this number stay at 0
until the problem shows up. Is something causing a deadlock that FB
cannot properly detect? How to analyze such a problem?
Best regards
Freddy Ertl
Von: firebird-support@yahoogroups.com
[mailto:firebird-support@yahoogroups.com]
Gesendet: Dienstag, 9. Mai 2017 13:48
An: firebird-support@yahoogroups.com
Betreff: Re: [firebird-support] Firebird SuperClassic hangs
Hi Freddy,
Try to use optimized Firebird configuration
https://ib-aid.com/en/optimized-firebird-configuration/
As Sean already told, hang could be caused by very long processing of
some requests - extremely long queues in lock table, or related with
excessive number of record versions (Max Versions in database
statistics), or with other reasons. I would recommend to perform
detailed investigation of the problem.
Regards,
Alexey Kovyazin
IBSurgeon www.ib-aid.com<http://www.ib-aid.com>
Hi,
we’re running Firebird 2.5.7 SuperClassic on Windows Server 2012R2 as
part of a web application. Database is around 130GB with millions of
transaction per day. From time to time Firebird hangs. It does not
respond to any client. It’s also not possible to connect locally to
the server. The interesting thing is the memory consumption that drops
from 5-7GB to around 50MB and the CPU load goes down to 0%. When
Firebird is in this state, I also see a lot of waiting threads in the
Task Manager under “Analyze wait chain”. The only way to get out, is
to stop the service. This takes longer than normal and sometimes shows
some kind of timeout. But the process is stopped and can be started
again. I also ran fb_lock_print when the problem occurred. It shows
something under “Deadlock scans” which is not normal, I think.
LOCK_HEADER BLOCK
Version: 145, Active owner: 0, Length: 25165824, Used: 24798216
Flags: 0x0001
Enqs: 17157097538, Converts: 22693011, Rejects: 12135777, Blocks:
93039760
Deadlock scans: 289, Deadlocks: 1, Scan interval: 10
Acquires: 18346589405, Acquire blocks: 1203176111, Spin count: 0
Mutex wait: 6.6%
Hash slots: 1009, Hash lengths (min/avg/max): 47/ 67/ 93
Remove node: 0, Insert queue: 0, Insert prior: 0
Owners (151): forward: 30704, backward: 21097392
Free owners (4): forward: 750216, backward: 24346456
Free locks (10120): forward: 28728, backward: 693760
Free requests (7877): forward: 8570432, backward: 1678000
Lock Ordering: Enabled
Has anybody experienced something like this? Thanks in advance.
Best regards
Freddy Ertl
[Non-text portions of this message have been removed]
