You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have been using bees (updated to the latest version) on my BTRFS NAS for years with great satisfaction, however it uses much IO bandwidth and sometimes thrashes badly my BTRFS disks and system performance, with a system load going above 5-6 for hours (bees high activity sometimes lasting for days...)
So I wanted to limit the system load and added "--loadavg-target 3" to OPTIONS in beesd.conf and restarted bees.
Immediately the system load started rising and quickly went well over 20, and eventually my system OOM killer kicked in and killed bees. Weird !
Then I figured out I had missed the "=" sign in "--loadavg-target=3", so I added it and rebooted (because I wansn't sure of the state of my system after an OOM kill).
Alas even with this "--loadavg-target=3" setting the system load quickly rised above 10+ so I stopped bees, completely removed the "--loadavg-target" option, restarted, and things went back to usual : with a load high, but sustainable.
So I wonder why the "--loadavg-target=3" did the exact contrary of what I was expecting...
Checking my system logs, it however shows that it was actually understood :
beesd[3096]: bees[3096]: setting load average target to 3
beesd[3096]: bees[3096]: setting worker thread pool minimum size to 0
beesd[3096]: bees[3096]: setting worker thread pool maximum size to 2
beesd[3096]: bees[3096]: setting root path to '/run/bees/mnt/<some_uuid>'
beesd[3096]: bees[3096]: Starting bees main loop...
bees doesn't look at the loadavg values you are looking at, instead it looks at an inverse value which extrapolates the immediate current value from the other values (thus reversing the average). This may explain your observation.
Still, it should not have the opposite effect of not running with a limiter at all. Maybe bees doesn't respect some other parameters properly when using the limiter? Maybe spawning too many threads? @Zygo
Hello,
I have been using bees (updated to the latest version) on my BTRFS NAS for years with great satisfaction, however it uses much IO bandwidth and sometimes thrashes badly my BTRFS disks and system performance, with a system load going above 5-6 for hours (bees high activity sometimes lasting for days...)
So I wanted to limit the system load and added "--loadavg-target 3" to OPTIONS in beesd.conf and restarted bees.
Immediately the system load started rising and quickly went well over 20, and eventually my system OOM killer kicked in and killed bees. Weird !
Then I figured out I had missed the "=" sign in "--loadavg-target=3", so I added it and rebooted (because I wansn't sure of the state of my system after an OOM kill).
Alas even with this "--loadavg-target=3" setting the system load quickly rised above 10+ so I stopped bees, completely removed the "--loadavg-target" option, restarted, and things went back to usual : with a load high, but sustainable.
So I wonder why the "--loadavg-target=3" did the exact contrary of what I was expecting...
Checking my system logs, it however shows that it was actually understood :
beesd[3096]: bees[3096]: setting load average target to 3
beesd[3096]: bees[3096]: setting worker thread pool minimum size to 0
beesd[3096]: bees[3096]: setting worker thread pool maximum size to 2
beesd[3096]: bees[3096]: setting root path to '/run/bees/mnt/<some_uuid>'
beesd[3096]: bees[3096]: Starting bees main loop...
Some system info :
CPU:
Info: dual core model: Intel Celeron G1610T bits: 64 type: MCP cache: L2: 512 KiB
Speed (MHz): avg: 1696 min/max: 1600/2300 cores: 1: 1696 2: 1696
RAM : 8 GB
BTRFS RAID-5 : 4 x 4TB WD RED HDs
bees options :
OPTIONS="--strip-paths --no-timestamps --verbose=6"
DB_SIZE=$((464$AL16M)) # 4G in bytes
The text was updated successfully, but these errors were encountered: