-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CPU usage increases after folder scans (and hence, over time) #9417
Comments
Take a CPU profile? |
Wow, nice, kudos for this great documentation on how to grab a profile!
Hope this helps. |
Looks like it was running a database GC in the second profile. May have been an unlucky coincidence. Take another one? |
Sure, no problem — to decrease chances of anything else interfering, I grabbed three in a row: |
The increase seems to be in findRunnable, which could indicate a lot of goroutines (a goroutine leak somewhere). I ran Syncthing for a couple of hours with a 5s rescan on one of my folders, and saw no increase in goroutines at least. (Possibly a little increase in background CPU usage but within the margin of error, small fractions of a percent.) Could be something as simple as memory getting fragmented increase GC work or something, as well. |
Interesting, sure, memory fragmentation due to many rescans (after long runtimes) seems quite likely. The reason why I stumbled upon this is actually since I am performing power consumption monitoring for the home server running Syncthing (and other things), and the x86_64 machine (Intel Pentium Silver N6005) usually uses 3 W after reboot, but was using >4 W after a week, growing towards this value with an almost linear increase over time. Of course, still not a lot, but 30 % increase (which of course also translates in UPS runtime) was reason for the nerd to start investigating, and the power consumption data basically looked as if there was a "leak" (not in memory, but in CPU usage). Then I found the increased number of Do you think it is likely that configuration can trigger this? Is there a way to dump the number of goroutines at runtime, then I could confirm that this number is also constant for me? If we don't find the cause, or you think it is not fruitful to delve deeper, that is of course also perfectly fine with me — then I will likely work around this with a daily restart or decrease the interval for full scans (or both) for the system. |
You can enable the built in profiler by running with |
It's also not seen as an increase in threads, GC time, file system operations, or open file descriptors (I'll spare you graphs not showing an increase). |
Many thanks, that's very enlightening! The built-in profiler which I missed up to now is really great. ❤️ I will also take a look, but I will probably not see anything new, my Go knowledge is very basic at the moment. |
I can confirm that I also see CPU usage increase after a few days of uptime. Edit: @calmh: Could you let me know which metric you used for the cpu usage? I can only see process_cpu_seconds_total in the /metrics endpoint but no current cpu usage |
For completeness, Alex has also reported this in the forums: Sadly, I don't have enough monitoring history to confirm (I never saw a noticeable increase before, but my monitoring was just worse in the past). |
I've run into this problem as well. A walk through the bowels of go's timer internals reveals that there are hundreds of timers with a two second period being processed. With the helpful hints about the scan routines, I found this path missing a timer stop:
|
@colingibbs1 That's a great find! |
Argh, let me do some coding for Syncthing for once and I add a resource leak. I'll fix it asap (while I should review stuff instead of course, but I wanna fix :) ). Thanks a lot for finding this! |
Move the ticker closer to where it's used and defer stop it to avoid missing a branch.
inotify
watches enabledObservation
CPU usage is low in general (< 1 % on a small Intel SoC), but keeps growing slowly over time (after >2 days) to 2 % and above, i.e. by over a factor of two (in idle). After prolonged runtime of some weeks, I also observed > 4 %.
Reproduction steps
Either wait ;-), or run many folder rescans. Slowly hitting "Rescan all folders" about 80 times, then waiting until everything has settled down, CPU usage has increased, too.
So likely, the regular hourly scan is causing it.
Further information
Initially reported as:
https://forum.syncthing.net/t/slowly-increasing-cpu-usage-over-time/21639/2
(until I found a reproducer).
Note I also observe a higher rate of syscalls such as:
in this state, but not sure whether this is really related.
The text was updated successfully, but these errors were encountered: