Runaway CPU usage for 64bit BitCoin (Linux Client)

I did a forum search, didn’t see this mentioned by anyone yet.

I have 5 Bit Coin clients, some running Windows Bit Coin, others running Linux Bit Coin.

I only have one 64 bit Linux system, but when I run Bit Coin, after about 10 minutes, the CPU usage runs away and brings the system to a stall unless I kill the Bit Coin application.

Now I have 2 other computers running a 32 bit Linux Bit Coin client and they work just fine, no runaway CPU.

I’ve tried running the 32 bit Bit Coin on the 64 bit Linux system, but the same thing still happens. My 64 bit Linux system has a dual-core processor, and even when I choose the “use only 1 processor” option, after a while Bit Coin ends up using both CPU to the 100% max that it can.

Is this a bug that only affects 64 bit Linux users at the moment?

Using the latest version 0.3.0 from the front page of the website.

System OS: Linux Mandriva 2010.0 (64 bit) RAM 16GB Processor - Intel Dual-Core 3.06 CPU

Feedback or advice welcome.

Edit by Xunie: I merged this thread with the other “Bitcoin slowing down your Linux system?” thread, so things my be confusing for a second, heh.

On a side note, I’ve tracked down the other GUI issue.

The “minimize to tray instead of taskbar” is what was eating up all the CPU on my system. After I turned this off, the issue was resolved with Runaway CPU.

This only seems to affect the 64 bit Client, as the 32 bit Clients I have don’t seem to be affected by this.

I did notice on the 64 bit Client, what happens is, it spawns multiple “tray” icons until X server finally kills over, so I guess I should submit that as a bug to somewhere? Huh

hardcoding to 19 should work, also you could just change PRIO_MIN to PRIO_MAX which would basically do the same thing, (technically PRIO_MAX is defined as 20 in the linux kernel source)

I agree that there authors saw some practicality in changing the priority depending on what the function is doing, but personally Id rather just have it not touch the priority at all, as the program will work just fine sitting at lowest priority all day.. I dont want it ever stealing any priority from any process regardless of what the thread is doing.. (maybe it would be a good suggestion to make this a command line parameter to disable/enable automatic priority adjustment - Im sure theres many who would prefer to keep the automatic priority scheduling in place, but also plenty that don’t want any part of it)

Quote from: asdfman on July 12, 2010, 11:31:22 PM

hardcoding to 19 should work, also you could just change PRIO_MIN to PRIO_MAX which would basically do the same thing, (technically PRIO_MAX is defined as 20 in the linux kernel source)

I agree that there authors saw some practicality in changing the priority depending on what the function is doing, but personally Id rather just have it not touch the priority at all, as the program will work just fine sitting at lowest priority all day.. I dont want it ever stealing any priority from any process regardless of what the thread is doing.. (maybe it would be a good suggestion to make this a command line parameter to disable/enable automatic priority adjustment - Im sure theres many who would prefer to keep the automatic priority scheduling in place, but also plenty that don’t want any part of it)

Good point. I just wanted to test if it made a difference (I suspect it will). But after reading the other topics, seems the fix was already checked into the SVN, just not in time for the release so there is no sense in me trying a fix that which is already fixed code wise, hehe.

I agree though, it just needs to run at the lowest prioirty at all times, I mean it’s suppose to run off of idle CPU and a nice level of 2 isn’t far from shared CPU cycles than idle CPU cycles in my opinion.

One fairly simple workaround is to run bitcoind as a user other than root. Since bitcoin does not require root permissions it will run just fine and it won’t be able to set a negative niceness (only root can do that). That will ensure that the highest priority bitcoind can use is 0 (normal).

After it initially tries incorrectly to set itself to the lowest priority, the generate thread only changes its priority again temporarily when it finds a block.  When you’ve found a block, you should want it to hurry up and broadcast it as soon a possible before someone else finds one and makes yours invalid.  The generate thread only changes to higher priority for less than a second every few days.

There should be a 0.3.1 release for this soon.  There are a few other issues we need to look at fixing in 0.3.1 before making a release.

Quote from: knightmb on July 12, 2010, 10:39:13 PM

On a side note, I’ve tracked down the other GUI issue.

The “minimize to tray instead of taskbar” is what was eating up all the CPU on my system. After I turned this off, the issue was resolved with Runaway CPU.

This only seems to affect the 64 bit Client, as the 32 bit Clients I have don’t seem to be affected by this.

I did notice on the 64 bit Client, what happens is, it spawns multiple “tray” icons until X server finally kills over, so I guess I should submit that as a bug to somewhere?  That’s interesting.  I know the minimize to tray on Ubuntu is very clunky, but I didn’t know it had a CPU peg problem too.  Anyone else able to reproduce this problem?  We had this feature disabled on Linux before, but then it seemed better to have the imperfect UI than to lose the feature entirely.  I’m thinking we should disable it again on Linux.

Quote from: satoshi on July 14, 2010, 06:45:53 PM

After it initially tries incorrectly to set itself to the lowest priority, the generate thread only changes its priority again temporarily when it finds a block. When you’ve found a block, you should want it to hurry up and broadcast it as soon a possible before someone else finds one and makes yours invalid. The generate thread only changes to higher priority for less than a second every few days.

There should be a 0.3.1 release for this soon. There are a few other issues we need to look at fixing in 0.3.1 before making a release.

Quote from: knightmb on July 12, 2010, 10:39:13 PM

On a side note, I’ve tracked down the other GUI issue.

The “minimize to tray instead of taskbar” is what was eating up all the CPU on my system. After I turned this off, the issue was resolved with Runaway CPU.

This only seems to affect the 64 bit Client, as the 32 bit Clients I have don’t seem to be affected by this.

I did notice on the 64 bit Client, what happens is, it spawns multiple “tray” icons until X server finally kills over, so I guess I should submit that as a bug to somewhere?

That’s interesting. I know the minimize to tray on Ubuntu is very clunky, but I didn’t know it had a CPU peg problem too. Anyone else able to reproduce this problem? We had this feature disabled on Linux before, but then it seemed better to have the imperfect UI than to lose the feature entirely. I’m thinking we should disable it again on Linux.

It only seems to happen if A) you minimize to tray, later bring it back up, minimize again, bring it back up. It starts stacking tray icons out (but they are blank, but still labeled as BitCoin) B) sometimes the program does it randomly

I’ll turn it back on with mine to make a screen shot, doesn’t take long for it to happen, hehe.

Ok, easy to replicate (well for me anyway)

64bit Client Linux

Having either the “minimize to tray instead of taskbar” or “minimize on close” options checked will cause the bug.

First thing you notice (as per the first screen-shot), the tasktray is being filled up with invisible icons “spaces”. If you hover the mouse over them, they all say “Bitcoin (not connected” but the one that does have an Bit Coin icon, just says “Bitcoin” and that’s what you can bring the window back up with.

If you just have “minimize on close” checked, it still sends it to task tray causing the bugs.

After a while, all your CPU will be consumed by the X server, even after you close Bitcoin, I think some process stay stuck in memory, not sure.

The 32bit Client for Linux doesn’t have this exact issue. I will still make at least one invisible Bitcoin icon, but doesn’t tear up the CPU later. So the 32 bit client sort-a has the bug, but not in a way to bring the system down after a short while.

Could you make it possible to reenable that feature with a startup switch or even compile flag? I like it a lot, and I don’t have this issue.

OK, the undocumented switch “-minimizetotray” which re-enables the option.

I uploaded the change to SVN.