On 6/7/21 6:27 PM, Martin Wilck wrote:
On So, 2021-06-06 at 11:35 -0500, Roger Heflin wrote:
This might be a simpler way to control the number of threads at the
same time.
On large machines (cpu wise, memory wise and disk wise). I have
only seen lvm timeout when udev_children is set to default. The
default seems to be set wrong, and the default seemed to be tuned for
a case where a large number of the disks on the machine were going to
be timing out (or otherwise really really slow), so to support this
case a huge number of threads was required.. I found that with it
set to default on a close to 100 core machine that udev got about 87
minutes of time during the boot up (about 2 minutes). Changing the
number of children to =4 resulted in udev getting around 2-3 minutes
in the same window, and actually resulted in a much faster boot up
and a much more reliable boot up (no timeouts).
Wow, setting the number of children to 4 is pretty radical. We decrease
this parameter often on large machines, but we never went all the way
down to a single-digit number. If that's really necessary under
whatever circumstances, it's clear evidence of udev's deficiencies.
I am not sure if it's better than Heming's suggestion though. It would
affect every device in the system. It wouldn't even be possible to
process more than 4 totally different events at the same time.
hello
I tested udev.children_max with value 1, 2 & 4. The results showed it
didn't take effect, and the booting time even longer than before.
This solution may suite for some special cases.
(my env: kvm-qemu vm, 6vpu, 22G mem, 1015 disks)
Regards
heming
_______________________________________________
linux-lvm mailing list
linux-lvm@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
