Linux Bitcoin 'nice', but still hogging CPU

[Ground Loop]

I ran into a curious issue with the x64 version of bitcoind for Linux.
I have it running on 8 cores, with the task re-niced to "19" (ie, most nice).

However, it still seems to impact performance of the system for tasks such as compiling and executing, to the tune of 2x speed degradation.

Reducing the number of active cores improves the speed of other tasks, but I have to stop it altogether to let other higher-priority tasks run at full speed.  The impact is not subtle -- things that used to take a minute now take two.

I confirmed that the nice level is "19", and the other tasks are at standard "0", yet bitcoind still causes them to take twice as long.

Memory consumption seems reasonable, and it's not swap-happy.

Any ideas?

[knightmb]

I ran into a curious issue with the x64 version of bitcoind for Linux.
I have it running on 8 cores, with the task re-niced to "19" (ie, most nice).

However, it still seems to impact performance of the system for tasks such as compiling and executing, to the tune of 2x speed degradation.

Reducing the number of active cores improves the speed of other tasks, but I have to stop it altogether to let other higher-priority tasks run at full speed.  The impact is not subtle -- things that used to take a minute now take two.

I confirmed that the nice level is "19", and the other tasks are at standard "0", yet bitcoind still causes them to take twice as long.

Memory consumption seems reasonable, and it's not swap-happy.

Any ideas?

Yeah, the nice 19 is still half down from 0, so even though the nice level is 19, there are still -19 levels beyond that of prioirty. So while 19 is as low as it gets, your task running at 0 are not at the top of the priority queue.

[NewLibertyStandard]

I ran into a curious issue with the x64 version of bitcoind for Linux.
I have it running on 8 cores, with the task re-niced to "19" (ie, most nice).

However, it still seems to impact performance of the system for tasks such as compiling and executing, to the tune of 2x speed degradation.

Reducing the number of active cores improves the speed of other tasks, but I have to stop it altogether to let other higher-priority tasks run at full speed.  The impact is not subtle -- things that used to take a minute now take two.

I confirmed that the nice level is "19", and the other tasks are at standard "0", yet bitcoind still causes them to take twice as long.

Memory consumption seems reasonable, and it's not swap-happy.

Any ideas?

Are four of those cores hyper threaded? I get more hashes using half my threads than using all of them when I have hyper threading. And the system is more responsive too.

[Ground Loop]

Interesting, knight.

I thought nice=19 would allocate (at most) 5% of the CPU: (20 - n / 20)  That's how it used to work, but the scheduler has been through some changes.

NewLibertyStandard: It's not hyper-threading, but I'll try running 4 and see what happens to the rate.  I wouldn't have thought...