Skip to content
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

Single CPU core fully utilized with Trace session [CORE5203] #5484

firebird-automations opened this issue Apr 21, 2016 · 5 comments


Copy link

Submitted by: Thomas Steinmaurer (tsteinmaurer)

I'm basically seeking for assistance pin-pointing an issue here with
Firebird 3 SuperServer 32-bit on Windows 10 Prof., as it seems, in the
context of the Trace API. This all is not an issue with Firebird 2.5.

Unfortunately, it is only reproducible in FB TraceManager at the moment.
I haven't been able to reproduce it with e.g. a mix of isql and
fbtracemgr.exe for example.

When starting a trace session with e.g. the following configuration:

database = employee
enabled = true
log_statement_prepare = true
log_statement_free = true
log_statement_finish = true
log_procedure_finish = true
log_trigger_finish = true
print_plan = true
print_perf = true
log_function_finish = true
exclude_filter = %RDB$%
time_threshold = 0
max_sql_length = 2048

and triggering a few monitoring table queries behind the scene in a
particular area of our product, a single thread in firebird.exe starts
to fully utilize a single CPU core. When I start the trace session with
an additional exclude_filter part %MON$%, the problem disappears.

I guess not very helpful, but this is the stack trace of the high CPU
offending thread in firebird.exe according to SysInternals process explorer.


I'm afraid, not very helpful. :-(

What else could I provide so that you can investigate the offending
thread? I'm better in diagnosing JVM stuff than native.

I'm aware, this all is vague and I would prefer a simple isql based test
case as well, but I failed so far.

Commits: 41e9f3f 1184d3e

Copy link
Collaborator Author

Modified by: @AlexPeshkoff

assignee: Alexander Peshkov [ alexpeshkoff ]

Copy link
Collaborator Author

Modified by: @AlexPeshkoff

reporter: Alexander Peshkov [ alexpeshkoff ] => Thomas Steinmaurer [ tsteinmaurer ]

Copy link
Collaborator Author

Commented by: @AlexPeshkoff

Thomas, as a temporal workaround I recommend use of isc_info_svc_to_eof when reading service data.

BTW, it's more efficient in general (using bigger network packets) therefore recommended when service can produce a lot of data. Our utilities fbsvcmgr & fbtracemgr are using it to access trace data.

Copy link
Collaborator Author

Modified by: @AlexPeshkoff

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

Fix Version: 3.0.1 [ 10730 ]

Fix Version: 4.0 Alpha 1 [ 10731 ]

Copy link
Collaborator Author

Modified by: @pavel-zotov

status: Resolved [ 5 ] => Resolved [ 5 ]

QA Status: No test => Cannot be tested

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment