We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
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?
to your account
Submitted by: @pavel-zotov
when fbtracemgr is launched (w/o any output of watching info) it loads CPU up to 52-57%
First rows of of `top` in my case:
top - 00:15:19 up 25 days, 10:55, 6 users, load average: 2.68, 1.83, 0.90
Tasks: 388 total, 1 running, 387 sleeping, 0 stopped, 0 zombie
Cpu(s): 10.8%us, 5.5%sy, 0.0%ni, 79.3%id, 4.0%wa, 0.0%hi, 0.4%si, 0.0%st
Mem: 16467720k total, 16377168k used, 90552k free, 4028k buffers
Swap: 16383992k total, 343412k used, 16040580k free, 13045100k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
30122 root 20 0 192m 36m 20m S 70.0 0.2 5:01.46 fb_inet_server
30434 firebird 20 0 153m 8352 6144 S 52.7 0.1 0:18.32 fbtracemgr
27616 root 20 0 262m 38m 21m S 1.0 0.2 0:05.05 fb_inet_server
30950 root 20 0 230m 72m 23m S 0.7 0.5 5:46.64 fb_inet_server
[firebird@firebird firebird]$ uname -a
Linux firebird 220.127.116.11-85.fc13.x86_64 #1 SMP Thu May 6 18:09:49 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux
[firebird@firebird firebird]$ ulimit -a
core file size (blocks, -c) unlimited
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 128524
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 65536
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 10240
cpu time (seconds, -t) unlimited
max user processes (-u) 16384
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
Commits: 6080eec 645c412
The text was updated successfully, but these errors were encountered:
Component: TRACEMGR [ 10140 ]
Sorry, something went wrong.
assignee: Alexander Peshkov [ alexpeshkoff ]
Commented by: @AlexPeshkoff
The bug used to happen due to incorrectly calculated timeout for sem_timedwait().
summary: fbtracemgr loads CPU up to ~55% after any query in isql is finished => fbtracemgr loads CPU up to ~55% when no activity is present
status: Open [ 1 ] => Resolved [ 5 ]
resolution: Fixed [ 1 ]
Fix Version: 2.5.2 [ 10450 ]
Fix Version: 3.0 Alpha 1 [ 10331 ]
status: Resolved [ 5 ] => Closed [ 6 ]
status: Closed [ 6 ] => Closed [ 6 ]
QA Status: Cannot be tested
No branches or pull requests