Since about 2 weeks I have a sudden memory issue with 1 of our Firebird servers.

For context: We have servers on 4 physical locations, each with a VM dedicated to Firebird and the connecting ERP pack. Each FireBird instance hosts 4-8 databases. The last change was about 4 weeks ago to all of these servers simultaneously, a "before insert/update" trigger that deletes a value on another table when the field on that table gains a certain value. No Firebird update, no ERP update.

2 weeks ago, 1 of these firebird instances started acting up, having very high load. Thinking the database was just growing, we increased cores to 8 and RAM to 32GB. This is our biggest instance, so we did not think much of it. However since 2 weeks ago the issue with the server being maxed out is returning every couple of days, today it even only took about 8 hours to go from freshly started to 30GB memory and 93% CPU usage! To compare, the next biggest which is about 20% smaller and about 25% less users, is only using 5GB.

Again, to be clear, this is the only server having this issue.

It feels like there is a memory leak or some kind of loop. I've tried doing a backup/restore and also deleting about 15K of old records from a certain table which causes freezing ERP system since that same day, but nothing seems to help. Rebooting either firebird or the entire VM causes it to start at a normal level, but always gradually increase until the server performance just goes down the drain, causing issues for all users.

In firebird.log there are daily entries with error 10054 but they have been occuring daily since early 2022 apparently. (i wasn't on the team yet back then) I also can't find anything in windows event viewer related to firebird.

  • Did you check MON$MEMORY_USAGE to find out what memory may be used for? Commented Dec 5, 2023 at 22:35

1 Answer 1


I haven't used Firebird 4, but I have used previous versions all the way from 1.5.

When we encountered a similar problem, we discovered that the cause was a transaction that had not been committed and released. Every time, an operation was done on that row(s), it would make a copy of them. That causes increased memory and/or storage depending on setup. And every access that involves that row(s), would cause it to read every copy it had made.

The solution was to find that one place in the program where the transaction was not correct and to fix it. That one place, we were committing but not releasing the transaction.

You can use the system monitoring tables to find out which table and user the problem is at/with.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.