This may be the problem fixed in
e9272225e6bed840b00eef1c817b188c172338ee ("vfs: fix vnlru marker
handling for filtered/unfiltered cases").However, there is a long standing performance bug where if vnode limit is hit, and there is nothing to reclaim, the code is just going to sleep for one second. On 3/28/21, Stefan Esser <s...@freebsd.org> wrote: > Am 28.03.21 um 17:44 schrieb Andriy Gapon: >> On 28/03/2021 17:39, Stefan Esser wrote: >>> After a period of high load, my now idle system needs 4 to 10 seconds to >>> run any trivial command - even after 20 minutes of no load ... >>> >>> >>> I have run some Monte-Carlo simulations for a few hours, with initially >>> 35 >>> processes running in parallel for some 10 seconds each. >> >> I saw somewhat similar symptoms with 13-CURRENT some time ago. >> To me it looked like even small kernel memory allocations took a very long >> time. >> But it was hard to properly diagnose that as my favorite tool, dtrace, was >> also >> affected by the same problem. > > That could have been the case - but I had to reboot to recover the system. > > I had let it sit idle fpr a few hours and the last "time uptime" before > the reboot took 15 second real time to complete. > > Response from within the shell (e.g. "echo *") was instantaneous, though. > > I tried to trace the program execution of "uptime" with truss and found, > that the loading of shared libraries proceeded at about one or two per > second until all were attached and then the program quickly printed the > expected results. > > I could probably recreate the issue by running the same set of programs > that triggered it a few hours ago, but this is a production system and > I need it to be operational through the week ... > > Regards, STefan > > -- Mateusz Guzik <mjguzik gmail.com> _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
