Issue Details (XML | Word | Printable)

Key: CORE-3770
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Alexander Peshkov
Reporter: Pavel Zotov
Votes: 0
Watchers: 4

If you were logged in you would be able to see more operations.
Firebird Core

fbtracemgr loads CPU up to ~55% when no activity is present

Created: 21/Feb/12 06:49 PM   Updated: 13/Jul/15 09:27 AM
Component/s: TRACEMGR
Affects Version/s: 2.5.1
Fix Version/s: 2.5.2, 3.0 Alpha 1

QA Status: Cannot be tested

 Description  « Hide

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:

-bash-4.1$ top
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

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 #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

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Alexander Peshkov added a comment - 22/Feb/12 08:26 AM - edited
The bug used to happen due to incorrectly calculated timeout for sem_timedwait().