https://bugzilla.redhat.com/show_bug.cgi?id=1069718
--- Comment #1 from Stephen Tweedie <[email protected]> --- Simple test, replicating the results seen with docker but just using simple regular file bind mounts: Using private mounts (because we're already looking into the kernel scaling problems with rshared) # make --mount-rprivate / # mkdir -p /tmp/mnt # cd /tmp/mnt # touch foo # time for f in `seq 1 4000`; do echo $f; touch $f; mount --bind foo $f; done ... real 0m28.960s user 0m1.733s sys 0m5.690s and now waiting for dbus to settle: # ps augx --sort=cputime | tail -3 root 654 7.0 0.0 34680 1656 ? Ss 10:48 0:22 /usr/lib/systemd/systemd-logind root 1 8.7 22.4 930212 873216 ? Ss 10:48 0:27 /usr/lib/systemd/systemd dbus 655 13.6 0.0 37072 2016 ? Ssl 10:48 0:43 /bin/dbus-daemon So after 4000 bind mounts we're at 0.87gb RSS for systemd and 1m32s CPU time for systemd/dbus. Next, unmount: # time umount * ... real 1m26.550s user 0m28.378s sys 0m25.493s and once dbus activity settles again: # ps augx --sort=cputime | tail -3 root 1 12.4 27.9 1178420 1084420 ? Ss 10:48 1:12 /usr/lib/systemd/systemd dbus 655 14.9 8.0 372220 314008 ? Ssl 10:48 1:26 /bin/dbus-daemon (systemd-logind had despawned by the time I captured this) so 2m38s CPU time and >1GB RSS now, even ignoring systemd-logind. And repeat the mounts... # ps augx --sort=cputime | tail -3 root 12075 17.4 2.2 128180 89052 ? Ss 10:57 0:42 /usr/lib/systemd/systemd-logind root 1 13.3 27.9 1178420 1084444 ? Ss 10:48 1:42 /usr/lib/systemd/systemd dbus 655 17.5 8.0 372220 314008 ? Ssl 10:48 2:14 /bin/dbus-daemon and unmount... # ps augx --sort=cputime | tail -3 root 12075 19.5 2.2 128180 89052 ? Rs 10:57 1:09 /usr/lib/systemd/systemd-logind root 1 17.2 38.2 1558316 1484712 ? Ss 10:48 2:32 /usr/lib/systemd/systemd dbus 655 21.5 8.0 372220 314008 ? Rsl 10:48 3:09 /bin/dbus-daemon So after just two mount/umount cycles (of a trivial bind mount), I've accumulated 6m50s of CPU time in dbus/systemd, and systemd itself has grown to an RSS of > 1.4GB. After a short while it reduced back down to ~900MB, but no lower. This seems to be reasonably stable: after a third cycle it's again 1.4GB peak systemd RSS, and 11m48s cpu time. Bind mounts on regular files are pretty much standard technology for doing anything stateless, the numbers here are not particularly unrealistic; 1.4GB RSS for systemd is fairly excessive here. --Stephen -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ golang mailing list [email protected] https://lists.fedoraproject.org/mailman/listinfo/golang
