Am 27.04.2018 um 11:19 schrieb Roman Mamedov: > On Fri, 27 Apr 2018 11:06:46 +0200 > Linus Lüssing <linus.luessing@xxxxxxxxx> wrote: > >> When running a RAID check via: >> >> $ echo check > /sys/block/md127/md/sync_action >> >> The underlying system, especially a Linux container, becomes barely >> usable. Webservers run into timeouts etc. >> >> In top I see that md127_raid6 is run at priority 20. However some >> (10+) other kworker processes do not and run at priority -20 and >> consume a siginificant amount of sys CPU usage while the RAID check >> is in progress. >> >> Are there any suggested ways to tune/fix the priorization issue >> I'm having? >> >> The setup I'm having here is pretty low-cost, low-power. A Pi3 >> with 64 bit kernel, 5 SATA drives connected via USB, configured as >> RAID6. > > Raspberry Pi 3 has a quad-core CPU, do you actually see 400% CPU load from > resync? IIRC it wasn't this multi-threaded. And my guess is that you suffer > not from the CPU load, but from contention for access to HDD between user > tasks and the resync/check process. > > Try this patch: > > md: allow faster resync only on non-rotational media > https://www.spinics.net/lists/raid/msg60722.html the real problem ist that "dev.raid.speed_limit_max" is not doing wthat it promises, either set it low and raid-check for large arrays takes ages or set it high and you can't work serious on the machine it should automatically take away io-pressure when there is active IO and only use "dev.raid.speed_limit_max" when the system is otherwise idle dev.raid.speed_limit_min = 25000 dev.raid.speed_limit_max = 150000 -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
