CPU Usage #383
Labels
bug
A problem with current functionality, as opposed to missing functionality (enhancement)
frozen-due-to-age
Issues closed and untouched for a long time, together with being locked for discussion
Milestone
Comments
|
That doesn't look right for the "monitoring" stage; is it still doing the initial scan, or syncing files to another node? |
|
It has done the initial scan, and now is just ‘idle’ (in the gui). No other nodes were added actually.. I used btsync to sync my source code directory.. Im a node developer, and unfortunately the node_modules junk gets synced too. Thats the source of the 250k files. Dependencies. I also have an older macbook pro, which isn’t quite as fast as it used to be. That might be a factor too. Matej Kramny On Friday, 20 June 2014 at 10:29, Jakob Borg wrote:
|
|
Still, idle should be idle. That said, for that many files there are some inefficiencies... I did some recent fixes in this area that are not in the 0.8.15 release; if you like, you could give the binary below a spin and see what happens. https://nym.se/t/syncthing-darwin-amd64-v0.8.15-12-g8e8a579.tar.gz |
|
Syncthing does a periodic scan for changes (just looking at file timestamps), by default every 60 seconds. In most cases this takes a few milliseconds because all file metdata is cached and nothing has changed. If you have many files and you're memory constrained, the metadata might not stay in the filesystem cache. In that case you might want to increase the scan interval, paying the price of detecting changes slower. |
|
With the new version, i get the following Matej Kramny On Friday, 20 June 2014 at 10:42, Jakob Borg wrote:
|
|
Hm? |
|
idk, it doesn’t index the folder.. Matej Kramny On Friday, 20 June 2014 at 14:56, Jakob Borg wrote:
|
|
Did you mean to attach a screenshot or a log of some kind? |
|
Oh sorry the mail picture wasn't attached (facepalm)
|
|
Weird. Make sure you reload the GUI in your browser, if something could be cached? What does the console say? |
|
Cleared the cache in chrome.. console says I just removed the repo and added it back, same thing.. 'Unknown' state |
|
Well, weird. There's nothing that's really changed in the release I gave you that should have anything do with this. However, if the last line of output is "populating repository index" then it's still doing the initial scan of the repo. You should see i.e. at "ready to synchronize" it's done with the scan. It can take a while on the first startup. It still shouldn't be shown as unknown though in the meantime, so I'm not sure what's going on there. |
|
Hmm interesting.. Perhaps the index is already built, but its stuck somewhere. It uses 0% cpu and has no disk activity. However, trying to sync a different folder produces the same issue. Thanks for your help :P. Matej Kramny On Friday, 20 June 2014 at 16:55, Jakob Borg wrote:
|
|
Sounds like it's become stuck. I'd like know where. If you open a new terminal and run |
|
My terminal has limited scrollback, so i didn't get the whole thing.. Hope this helps. |
|
Alright, now that it works.. Its a bit faster, though every 60 seconds the cpu is maxed out for about 20-40 seconds. I suppose you have a faster mac. My is core duo 2009. |
|
Thanks for the traceback. That'll be tedious to work through, but it shows syncthing being deadlocked for the last 13 minutes, so there's a bug for sure at the end of it. Yeah the 60 second rescan is expected, although maxing out cpu for 30 seconds at the time is a bit painful. :/ This seems to be one of those few cases where subscribing to filesystem notifications instead (#9) would be a huge win. |
|
Thanks Jakob. If there’s anything i can do to help, please tell me :). I’d like to contribute, but idk where to start (or what needs to be done).. Matej Kramny On Friday, 20 June 2014 at 17:33, Jakob Borg wrote:
|
|
Well, in this case (as regards to cpu usage and efficiency), sit tight because that's the current focus. Can't make any promises for magic though. :/ The UI however is in HTML5 + angular–and certainly in need of some UI design–so anything you feel like adding there in terms of recommendations, tips or actual code is welcome. :) |
|
This is something that concerned me earlier, though I haven't experienced the issue on any of my machines. Implementing updates via a filesystem listener is probably worth investigating, though it's also probably a good idea to have a fallback. I have plenty of RAM, but my system's default inotify limit is only around 500K (inodes). If this post is correct and each listener only consumes about 1KB of kernel memory, that's (only) about 500MB. I don't know if there would be adverse effects of having large amounts of memory allocated for the kernel or if the CPU overhead at that point would exceed that of a manual file scan, but I know that changing the max inode listener count requires administrative access on most systems. |
Closed
|
I also have this issue: topCPU|MEM And then it goes back to the first one again. I think there is a loop causing it. |
st-review
added
the
frozen-due-to-age
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I have 240982 files to sync, and syncthing (understandably) uses quite a large proportion of the CPU to monitor the files.
Other than reducing the number of files synced, is there any way to lower cpu usage?
The text was updated successfully, but these errors were encountered: