|Subject||Re: AW: [firebird-support] Firebird SuperClassic hangs|
The only thing I can say that situation is not obvious, I suggest to ask for professional support:
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?
Von: firstname.lastname@example.org [mailto:email@example.com]
Gesendet: Dienstag, 9. Mai 2017 13:48
Betreff: Re: [firebird-support] Firebird SuperClassic hangs
Try to use 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.
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.
Version: 145, Active owner: 0, Length: 25165824, Used: 24798216
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.
[Non-text portions of this message have been removed]