Michael Grønager [ARCHIVE] on Nostr: 📅 Original date posted:2012-02-21 📝 Original message:Hi Wladimir / others, I ...
đź“… Original date posted:2012-02-21
đź“ť Original message:Hi Wladimir / others,
I just downloaded the latest (0.6 rc1) source of bitcoin-qt and built it using qt-creator on MacOSX 10.7.3. Nice and easy experience, even though I had to change BDB version to 5.1 ;)
However, when running it, it is using 100% CPU (after initial block chain download that is...)
* All activity in debug.log seems normal (blocks/txes/addresses are processes and accepted etc) so it is not stuck (at least not in the MessageThread)
* Sampling the process shows that the majority of time in each thread is used for:
** __semwait_signal
** kevent
** __select
** mach_msg_trap
** boost::date_time::micro_sec_clock
None of this would usually alert me - sleeping and waiting for conditions should not consume CPU, the only issue seems to be the last line which is called from qtipcserver.cpp line 31:
if(mq->timed_receive(&strBuf, sizeof(strBuf), nSize, nPriority, d))
As I see it this should not consume cpu either, but, it is the only thing that seems a bit strange..
Have you seen this before?
/M
đź“ť Original message:Hi Wladimir / others,
I just downloaded the latest (0.6 rc1) source of bitcoin-qt and built it using qt-creator on MacOSX 10.7.3. Nice and easy experience, even though I had to change BDB version to 5.1 ;)
However, when running it, it is using 100% CPU (after initial block chain download that is...)
* All activity in debug.log seems normal (blocks/txes/addresses are processes and accepted etc) so it is not stuck (at least not in the MessageThread)
* Sampling the process shows that the majority of time in each thread is used for:
** __semwait_signal
** kevent
** __select
** mach_msg_trap
** boost::date_time::micro_sec_clock
None of this would usually alert me - sleeping and waiting for conditions should not consume CPU, the only issue seems to be the last line which is called from qtipcserver.cpp line 31:
if(mq->timed_receive(&strBuf, sizeof(strBuf), nSize, nPriority, d))
As I see it this should not consume cpu either, but, it is the only thing that seems a bit strange..
Have you seen this before?
/M