New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FIREBIRD 3.X LINGER INTERNAL BUG [CORE5971] #6223
Comments
Modified by: @AlexPeshkoffassignee: Alexander Peshkov [ alexpeshkoff ] |
Commented by: @AlexPeshkoff Could not reproduce: Prepare database: And script: Test: Well, I've tested B3_0_Release but as far as I remember related code was not changed for a very long time (you may try yourself with snapshot build). And tested on gentoo, not ubuntu 1604. But I do not believe in such bug in ubuntu. May be database was somehow accessed when you've tried first time? |
Commented by: Pedro Santos (always) well seems the issue is not the linger parameter itself but something else causing the database to stay on memory. Test on a Ubuntu 16.04 running stock Firebird-3.0.4.33054-0.amd64.tar.gz cat qq.sql /opt/firebird/bin# ./isql -user sysdba -pas masterkey localhost:/opt/clidb/db/4763O00/9C08A100ECC9478DAE75615EF1AE747F/TETDB.FDB -i qq.sql; echo before;lsof -p `pidof firebird`|grep .FDB;sleep 15;echo after;lsof -p `pidof firebird`|grep .FDB
|
Modified by: @pcisarstatus: Resolved [ 5 ] => Closed [ 6 ] |
Commented by: Pedro Santos (always) Another test that probably shed some light on the mater: testing with employee.fdb altered LINGER parameter to 30 seconds (ALTER DATABASE SET LINGER TO 30;) and registered ib_udf.sql UDF (ib_udf.so) to have a clean db with udf's access. cat qq.sql select rdb$linger, div(4,2) as DIV_UDF_CALL from rdb$database;quit; ./isql -user sysdba -pas masterkey localhost:employee -i qq.sql; echo before;lsof -p `pidof firebird`|grep .fdb;sleep 60;echo after;lsof -p `pidof firebird`|grep .fdb RDB$LINGER DIV_UDF_CALL before Both the database and the udf still loaded on memory and will be kept there probably until firebird server restart lsof -p `pidof firebird` |grep udf after altering LINGER back to 0 (ALTER DATABASE SET LINGER TO 0;) RDB$LINGER DIV_UDF_CALL before lsof -p `pidof firebird` |grep udf |
Commented by: @AlexPeshkoff DId not reproduce: fbs3 /usr/home/firebird/B3_0_Release/gen/Debug/firebird/bin # ./isql -user sysdba -pas masterkey localhost:employee -i qq.sql; echo before;lsof -p `pidof firebird`|grep fdb;sleep 12;echo after;lsof -p `pidof firebird`|grep fdb RDB$LINGER DIV_UDF_CALL before I start to suppose this can reallly be ubuntu bug - but with this I definitely can't help. |
Submitted by: Pedro Santos (always)
using linux Ubuntu 16.04.5 LTS x64 with Firebird-3.0.4.33054-0.amd64.tar.gz
After recently migrated our production servers (linux x64) to Firebird 3.0.4 to use the LINGER feature (keeping the database in memory between requests from a web server) and after configuring the LINGER parameter of each database (each server has multiple client databases) we began noticing that the server memory is never recovered even when there's no client database activity.
So i download the release 3.0.4 source code did some reading i think i found the culprit:
firebird-R3_0_4\src\jrd\jrd.cpp line 6560:
...
FbLocalStatus s;
dbb->dbb_plugin_config->setReleaseDelay(&s, maxLinger > t ? (maxLinger - t) * 1000 * 1000 : 0);
check(&s);
...
the function setReleaseDelay will seems to accept the second parameter in miliseconds not microseconds.
so if for example configure the database with ALTER DATABASE SET LINGER TO 900;
(900 seconds or 15 minutes)
the value applied in the setReleaseDelay(..) will be 900 * 1000 * 1000 = 900000000 or 10.41 days from miliseconds or 15 minutes from microseconds
it seems the value is processed in miliseconds (10days) because in our production servers the databases never leave memory.
Already compiled and tested a internal 3.0.4 version without the 2 x 1000 and works as suposed to 900 seconds later the database file handle is released from memory.
(used lsof -p <firebird pid> to check firebird handles to the database files.)
i hope we can clear if the setReleaseDelay(..) value is microseconds or miliseconds
excuse my "English" and thanks
The text was updated successfully, but these errors were encountered: