Michael Gronager [ARCHIVE] on Nostr: 📅 Original date posted:2012-02-23 📝 Original message:A follow up on my mail ...
📅 Original date posted:2012-02-23
📝 Original message:A follow up on my mail from the other day (got it send from the wrong email address...)
I now exit the ipc thread at startup by inserting:
void ipcThread(void* parg)
{
ipcShutdown();
return;
Bitcoin-Qt is now running nicely using around 0.9% CPU. So it seems like the culprit was indeed line 31:
if(mq->timed_receive(&strBuf, sizeof(strBuf), nSize, nPriority, d))
Others, who have seen similar issues ?
Cheers,
M
On 21/02/2012, at 21:33, Michael Grønager wrote:
> 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
Published at
2023-06-07 03:08:42Event JSON
{
"id": "549c2b2adb1e39e08d8fe9e0a46a3029c10be316d3f99de9a5cc875c01cf63fd",
"pubkey": "9e3c76fd7eb862ca37f150391debc7baa4f8423eaa3f894c476a7d4360de9a02",
"created_at": 1686107322,
"kind": 1,
"tags": [
[
"e",
"421d990db104318c7b39478a96947f9501b9862954c82849c6dda8aa1fb9744a",
"",
"root"
],
[
"e",
"e62bc68187a1ed801ca9d577377148bf6f9fdfb1ba00411d8bcaa5d6fb128623",
"",
"reply"
],
[
"p",
"a277336e95d2d0a831fff67fc80d8082322689a88ede9f877fa246a02629a43f"
]
],
"content": "📅 Original date posted:2012-02-23\n📝 Original message:A follow up on my mail from the other day (got it send from the wrong email address...)\n\nI now exit the ipc thread at startup by inserting:\n\nvoid ipcThread(void* parg)\n{\n ipcShutdown();\n return;\n\nBitcoin-Qt is now running nicely using around 0.9% CPU. So it seems like the culprit was indeed line 31:\n\nif(mq-\u003etimed_receive(\u0026strBuf, sizeof(strBuf), nSize, nPriority, d))\n\nOthers, who have seen similar issues ?\n\nCheers,\n\nM \n\nOn 21/02/2012, at 21:33, Michael Grønager wrote:\n\n\u003e Hi Wladimir / others,\n\u003e \n\u003e 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 ;)\n\u003e \n\u003e However, when running it, it is using 100% CPU (after initial block chain download that is...)\n\u003e * 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)\n\u003e * Sampling the process shows that the majority of time in each thread is used for:\n\u003e ** __semwait_signal\n\u003e ** kevent\n\u003e ** __select\n\u003e ** mach_msg_trap\n\u003e ** boost::date_time::micro_sec_clock\n\u003e \n\u003e 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:\n\u003e \n\u003e if(mq-\u003etimed_receive(\u0026strBuf, sizeof(strBuf), nSize, nPriority, d))\n\u003e \n\u003e As I see it this should not consume cpu either, but, it is the only thing that seems a bit strange..\n\u003e \n\u003e Have you seen this before?\n\u003e \n\u003e /M",
"sig": "7e0b6524c5835c70bcfc31b8957599cd339fb964c1a2ff1483990f9eae294268d07092d5e803e24de1cb2ea26dabb7196d18f7d143bff06938c7e51bc3657896"
}