bitcoin auto-renice-ing
2010 Mar 8
See all posts
bitcoin auto-renice-ing @ Satoshi Nakamoto
- Author
-
Satoshi Nakamoto
- Email
-
satoshinakamotonetwork@proton.me
- Site
-
https://satoshinakamoto.network
fergalish
bitcoin auto-renice-ing
March 08, 2010, 09:29:56 AM
Hi, I run bitcoin at a nice level of 20 so as not to interfere with
other tasks. Every now and then, however, it seems to auto-adjust itself
to nice level 2, or even 0. It this by design? Frankly, such a thing
should be illegal for a linux application... it's a bit odd to say the
least.
Satoshi Nakamoto
March 15, 2010, 06:44:12 PM
It sets different priorities for each thread. The generate threads
run at PRIO_MIN. The other threads rarely take any CPU and run at
normal.
#define THREAD_PRIORITY_LOWEST PRIO_MIN
#define THREAD_PRIORITY_BELOW_NORMAL 2
#define THREAD_PRIORITY_NORMAL 0
The priorities converted from Windows priorities were probably from a
table like this:
"The following table shows the mapping between nice values and Win32
priorities. Refer to the Win32 documentation for SetThreadPriority() for
more information on Win32 priority issues.
| -20 to -16 |
THREAD_PRIORITY_HIGHEST |
| -15 to -6 |
THREAD_PRIORITY_ABOVE_NORMAL |
| -5 to +4 |
THREAD_PRIORITY_NORMAL |
| +5 to +14 |
THREAD_PRIORITY_BELOW_NORMAL |
| +15 to +19 |
THREAD_PRIORITY_LOWEST" |
If you have better values, suggestions welcome.
Also, there was some advice on the web that PRIO_PROCESS is used on
Linux because threads are processes. If that's not true, maybe it
accounts for unexpectedly setting the priority of the whole app.
// threads are processes on linux, so PRIO_PROCESS affects just the one thread
setpriority(PRIO_PROCESS, getpid(), nPriority);
asdfman
July 12, 2010, 08:05:57 AM
Hello,
This same behavior was bugging me too.. I would renice all the
threads to 19, as it was interrupting system responsiveness since
bitcoind was taking priority, but every so often the program would
automatically reset the priority to something that would disrupt system
responsiveness ..
so what I did was just edit util.h
and change the function that manipulates the priority:
inline void SetThreadPriority(int nPriority)
{
printf("No, were not changing any damn priority ");
}
and then recompiled bitcoind
now I just renice all the threads once, and they are stuck at what I
set them to until program exit (NI column staying at 19):
1 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%] Time: 03:59:40
2 [||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%] Uptime: 253 days(!), 01:12:27
Mem[||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||501/1255MB] Load: 4.01
Swp[|||||||||||||||||||||||||||||||||||||||||||||||||||||| 501/1004MB] Load average: 4.01 4.15 3.49
__ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __
| | |__ __| |__ |__||__ |__| | | | | | | | | | | | | __| __| | |
Avg: |__|.|__|% sy: |__ . __|% ni: __||__|.|__|% hi: |__|.|__|% si: |__|.|__|% wa: |__|.|__|% Tasks: __| __| | total, | running
PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command
4523 root 39 19 126M 46280 3424 S 0.0 3.6 0:00.66 `- bitcoind -gen -daemon
4534 root 39 19 126M 46280 3424 R 90.0 3.6 12:43.73 | `- bitcoind -gen -daemon
4533 root 39 19 126M 46280 3424 R 45.0 3.6 10:49.02 | `- bitcoind -gen -daemon
4532 root 39 19 126M 46280 3424 R 46.0 3.6 10:05.83 | `- bitcoind -gen -daemon
4531 root 39 19 126M 46280 3424 S 0.0 3.6 0:00.03 | `- bitcoind -gen -daemon
4530 root 39 19 126M 46280 3424 S 1.0 3.6 0:15.53 | `- bitcoind -gen -daemon
4529 root 39 19 126M 46280 3424 S 0.0 3.6 0:00.72 | `- bitcoind -gen -daemon
4527 root 39 19 126M 46280 3424 S 0.0 3.6 0:00.02 | `- bitcoind -gen -daemon
4526 root 39 19 126M 46280 3424 S 0.0 3.6 0:00.03 | `- bitcoind -gen -daemon
4525 root 39 19 126M 46280 3424 S 0.0 3.6 0:00.06 | `- bitcoind -gen -daemon
in my debug.log:
[root@raidserv] (~/.bitcoin)# grep "No," debug.log
No, were not changing any damn priority
No, were not changing any damn priority
No, were not changing any damn priority
No, were not changing any damn priority
...
So now I can leave bitcoind running all day long without me noticing
much...
asdfman
July 12, 2010, 08:21:14 AM
I think that this might be a bug... https://bitcointalk.org/index.php?topic=285.0
lachesis
July 12, 2010, 11:02:48 PM
Asdfman, what program is generating that output? I like it 
asdfman
July 12, 2010, 11:11:24 PM
lachesis - htop
its awesome.. has ANSI colors, you can fully configure it to display all
threads, tree view, etc ,etc
Satoshi Nakamoto
July 14, 2010, 05:38:31 PM
Laszlo corrected this, but unfortunately it was too late to make it
into 0.3.0. There will probably be a 0.3.1 soon though.
The problem is I used PRIO_MIN, I should have used PRIO_MAX for the
lowest priority. The OS isn't supposed to let you increase priority, so
the PRIO_MIN ought to leave it at priority 0.
bitcoin auto-renice-ing
2010 Mar 8 See all postsSatoshi Nakamoto
satoshinakamotonetwork@proton.me
https://satoshinakamoto.network
Hi, I run bitcoin at a nice level of 20 so as not to interfere with other tasks. Every now and then, however, it seems to auto-adjust itself to nice level 2, or even 0. It this by design? Frankly, such a thing should be illegal for a linux application... it's a bit odd to say the least.
It sets different priorities for each thread. The generate threads run at PRIO_MIN. The other threads rarely take any CPU and run at normal.
The priorities converted from Windows priorities were probably from a table like this:
"The following table shows the mapping between nice values and Win32 priorities. Refer to the Win32 documentation for SetThreadPriority() for more information on Win32 priority issues.
If you have better values, suggestions welcome.
Also, there was some advice on the web that PRIO_PROCESS is used on Linux because threads are processes. If that's not true, maybe it accounts for unexpectedly setting the priority of the whole app.
Hello,
This same behavior was bugging me too.. I would renice all the threads to 19, as it was interrupting system responsiveness since bitcoind was taking priority, but every so often the program would automatically reset the priority to something that would disrupt system responsiveness ..
so what I did was just edit
util.hand change the function that manipulates the priority:
and then recompiled bitcoind
now I just renice all the threads once, and they are stuck at what I set them to until program exit (NI column staying at 19):
in my debug.log:
[root@raidserv] (~/.bitcoin)# grep "No," debug.log
No, were not changing any damn priority
No, were not changing any damn priority
No, were not changing any damn priority
No, were not changing any damn priority
...
So now I can leave bitcoind running all day long without me noticing much...
I think that this might be a bug... https://bitcointalk.org/index.php?topic=285.0
Asdfman, what program is generating that output? I like it
lachesis - htop
its awesome.. has ANSI colors, you can fully configure it to display all threads, tree view, etc ,etc
Laszlo corrected this, but unfortunately it was too late to make it into 0.3.0. There will probably be a 0.3.1 soon though.
The problem is I used PRIO_MIN, I should have used PRIO_MAX for the lowest priority. The OS isn't supposed to let you increase priority, so the PRIO_MIN ought to leave it at priority 0.