Re: [voidlinux/void-packages] findutils updatedb gfind and find - high CPU usage on BTRFS (#4829)

zqqw at Sun, 25 Sep 2016 14:34:46 -0700
Thanks for the tip, that worked. ack also works and searched faster than my find command, although it still used all available CPU - it also looks like cgroups can throttle CPU usage of processes.
zqqw at Mon, 26 Sep 2016 14:12:34 -0700
$ sudo cgcreate -g cpu:zqqw $ ls /sys/fs/cgroup/cpu/zqqw/ cgroup.clone_children cgroup.procs cpu.cfs_period_us cpu.cfs_quota_us cpu.rt_period_us cpu.rt_runtime_us cpu.shares cpu.stat notify_on_release tasks $ sudo su /# echo 50000 >/sys/fs/cgroup/cpu/zqqw/cpu.cfs_quota_us /# cat /sys/fs/cgroup/cpu/zqqw/cpu.cfs_quota_us 50000 $ sudo cgexec -g cpu:zqqw ack "umount2" Tasks: 173 total, 2 running, 171 sleeping, 0 stopped, 0 zombie %Cpu(s): 50.3 us, 10.9 sy, 0.0 ni, 27.5 id, 9.9 wa, 0.0 hi, 1.3 si, 0.0 st KiB Mem : 1028592 total, 64088 free, 521636 used, 442868 buff/cache KiB Swap: 1116956 total, 1105308 free, 11648 used. 340936 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1293 root 20 0 10020 7488 3660 R 50.0 0.7 0:47.29 ack /usr/bin/ac 669 root 20 0 161540 76432 29896 S 3.9 7.4 3:01.91 Xorg And the search completed quietly in the background without switching the fans to high speed. mupdatedb seems to do an incremental update so is much more efficient than gupdatedb. It occurs to me now that the faster boot time indicates that BTRFS has improved the HDD data transfer speed. This has resulted in commands that were previously limited by disk access to run faster and now they are limited by CPU performance, so I should adjust to this new performance balance. Therefore this isn't really a bug so I'm closing it, but I think that findutils would definitely be improved by using nice in /etc/cron.daily/updatedb like in the mupdatedb equivalent, so it wouldn't block other desktop processes. Possibly maximum CPU usage could be throttled using cgroups, but some users might want it to run at maximum speed though.
zqqw at Mon, 26 Sep 2016 14:12:34 -0700
Closed #4829.