Bitcoin Forum
September 29, 2016, 11:48:00 PM *
News: Due to DDoS attacks, there may be periodic downtime.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: bitcoind - possibly process priority bug?  (Read 4577 times)
asdfman
Newbie
*
Offline Offline

Activity: 17


View Profile
July 12, 2010, 08:20:34 AM
 #1

This is kind of a continuation of this thread : http://bitcointalk.org/index.php?topic=72.0

I believe there might be a misunderstanding regarding the code for changing the process priorities... basically in short, I believe the intention is to set the processes to lowest priority (meaning most non intrusive, least priority in cpu scheduling) when the thread generating coins as it is very CPU intensive, and if not set to low priority, will noticeably decrease system responsiveness..

in main.cpp, there are multiple points in which the priority is changed to "lowest":

Code:
   while (fGenerateBitcoins)
    {
        SetThreadPriority(THREAD_PRIORITY_LOWEST);

in util.h THREAD_PRIORITY_LOWEST is set to PRIO_MIN:

Code:
#define THREAD_PRIORITY_LOWEST          PRIO_MIN

however, PRIO_MIN == the "minimum" in raw numeric terms (as in -20 < 20), but this actually means the highest priority in terms of how the OS interprets the number for the purpose of CPU scheduling

in the kernel sources resource.h:

Code:
#define PRIO_MIN        (-20)
#define PRIO_MAX        20

Quote
"A niceness of −20 is the highest priority and 19 or 20 is the lowest priority."
- http://en.wikipedia.org/wiki/Nice_(Unix)

I believe that THREAD_PRIORITY_LOWEST should be set to PRIO_MAX, otherwise the bitcoind starts disrupting system usabilty during coin generation..


Thanks
asdfman

1475192880
Hero Member
*
Offline Offline

Posts: 1475192880

View Profile Personal Message (Offline)

Ignore
1475192880
Reply with quote  #2

1475192880
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
laszlo
Full Member
***
Offline Offline

Activity: 199


View Profile
July 12, 2010, 12:19:14 PM
 #2

This is fixed in SVN but I think that was after the release was cut. 

The workaround is to run bitcoin like:
Quote
nice -n 19 ./bitcoind

..otherwise it hogs the CPU as you noted.

I spent some time experimenting with this and contrary to what the documentation states, on ubuntu you can actually adjust the priority to be more favorable (numerically lower) after raising it to a higher number.  I believe this might be due to selinux?  That seems non standard and I think on any 'normal' system using the usual behavior the generating thread will end up staying at the less favorable (numerically higher) priority even when an attempt to change it is made.

BC: 157fRrqAKrDyGHr1Bx3yDxeMv8Rh45aUet
asdfman
Newbie
*
Offline Offline

Activity: 17


View Profile
July 12, 2010, 01:56:10 PM
 #3

hmm.. the problem is, even if you set nice in the beginning or use renice, the 2 generating coin threads will move back to higher priority, do a ps -efL (in most modern linux distros anyway) to see the complete ps list for all threads, and you'll see the main process with the 'nice' setting, but other threads changing the priority...

for example in the other thread I posted in, http://bitcointalk.org/index.php?topic=72.0, in my process list copy/paste, the main process kept the nice value, and even if i manually niced the other threads, they would change automatically back to higher priority both in the listing, and I would definitely notice the degredation in my system responsiveness

Ive completely ripped out the priority changing function as Id prefer to set it myself and not have the program change it from what I want..
laszlo
Full Member
***
Offline Offline

Activity: 199


View Profile
July 12, 2010, 03:00:28 PM
 #4

Are you using some sort of alternate permission framework like selinux?  I believe some linux distros like ubuntu come with this by default.  Per the man page for setpriority (even on ubuntu), only root can lower (make more favorable) the priority so it should not be possible for the adjustment to work on linux.  Anyway the reason it tries to raise its scheduling priority is so that it can quickly save a generated block and then go back to low priority for generating again.  Your issues should all be fixed in SVN and you shouldn't have to manually set the priority anymore - you can just change the PRIO_MIN to your preferred priority, or use the PRIO_MAX macro.

http://www.kernel.org/doc/man-pages/online/pages/man2/getpriority.2.html

Quote
       The getpriority() call returns the highest priority (lowest numerical value)
       enjoyed by any of the specified processes.  The setpriority() call sets the
       priorities of all of the specified processes to the specified value.  Only the
       superuser may lower priorities.

BC: 157fRrqAKrDyGHr1Bx3yDxeMv8Rh45aUet
brightside
Newbie
*
Offline Offline

Activity: 1


View Profile
July 13, 2010, 04:46:05 AM
 #5

Thank you for the information.  Smiley

I attempted running bitcoind on my server today (Ubuntu 10.04), worked fine while it was downloading blocks but after a while it the ssh session stopped responding and even network pings went unanswered, so I had to do a manual shutdown and restart to get it under control again. Will try recompiling with the PRIO_MAX setting.
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!