Is it impossible now to stop syncthing from burning out mobile devices(?)

cpulimit stopped working, what am I supposed to do now? Apparently this is not a super major issue that this will likely actually damage batteries and such: https://github.com/syncthing/syncthing/issues/7927#event-5257416541

I can’t use syncthing now anymore (unless I want to damage the phone), why is this not relevant? I don’t understand, the response just made me feel quite sad. Why can’t there even be an option to fix this messy behavior? It feels like there is just no interest in heavier mobile use at all…

Edit: for further info, I used syncthing on the PinePhone with cpulimit. (This is a super low spec device, so it runs hot quicker than your whatever Samsung flagship monster. But hey, these phones also exist.) Now just letting syncthing run in idle goes to abysmal temperatures since cpulimit no longer sticks. Non-stop. And this is likely expected if folder scans run unthrottled, why can’t you just provide an option to throttle syncthing? I really really don’t get it

I’ve explained it on the ticket. Syncthing should not consume a lot of cpu if no files are changing.

You are trying yo treat the symptom and not the cause.

1 Like

What are you trying to sync specifically? If it is a part of some running application that keeps changing constantly, then Syncthing will keep trying to detect and sync the new changes, which will likely lead to constant higher CPU usage all the time.

If possible, please include screenshots of the Syncthing Web GUI from both sides, so that we can see how many folders there are, and whether there are any obvious clues visible in the GUI.

PS I have personally been using Syncthing on devices with much lower specs than the PinePhone with no serious issues, unless you go crazy and try to sync terabytes worth of data using a single-core CPU and 512 MB RAM or similar :wink:.

1 Like

Let’s assume you’re right, and the problem is just that Syncthing uses too much CPU for no good reason. Even in that case, it apparently thinks it needs to do X, which takes Y amount of CPU. If you could do the CPU limiting you want, you’d get Y/2 amount of CPU usage over twice the amount of time, for the same total amount of effort and battery usage. I mean, whatever it is Syncthing is doing, I can guarantee it’s not “let’s see how much CPU we can burn in ten seconds”, it’s more like “I need to do this thing which requires that many CPU cycles”.

If the reason is that filesystem notifications aren’t working and it’s falling back to periodic scans, maybe increase the scan interval.

I still feel this is discussing fixing the symptom and not the cause.

There is no reason syncthing should be continuously scanning, unless you are trying to sync something you shouldn’t.

Ensuring sane system temperatures is the OS’ job: Otherwise every program using CPU needed to implement system temperature sensor reading and cpu limiting on every single platform. That’s obviously not sensible (or even possible). If your system can’t keep its cpu cool enough at full load, it should throttle performance.

1 Like

What is the exact problem with the file watcher? Do you get actual errors when trying to use it? “Large” is a relative term. What size are the folders in question specifically? What is the actual number of files?

I would say that the continuous scanning option with its default value of 60 is definitely not designed for giant folders with millions of files in them, that’s for sure. This is also why we can tweak it to specific needs though.

1 Like

The issue is not about finding something interesting, but rather that specific information is often needed to be able to properly answer the question (or support request in this case).

This is really not that much, although I will agree that it does take some time to scan through a folder like that, especially if the CPU and/or I/O performance is weak.

I would personally suggest having a look at https://forum.syncthing.net/t/optimising-syncthing-for-low-end-hardware/14885. You may find some tweaks mentioned there useful. Also, not included in that topic, but how about simply running Syncthing with GOMAXPROCS=1 or similar? This will limit the available CPU cores to just 1, which should at least reduce the heat.

Old, but still relevant:

Does it really take that long on a fast machine to go through those folders? If yes, then I would say that something is not right here, unless the storage is super slow, but then the CPU usage shouldn’t be high anyway.

I can only add some stats from my side:

  • ~20s to scan 313,193 files and 28,997 folders on a fast desktop PC (mix of SSD and HDD, 70% CPU usage)
  • ~5m to scan 122,677 files and 13,179 folders on a slow tablet PC (eMMC and SD card, 60% CPU usage)

The second case probably has similar performance to the PinePhone, so yes, it does take a while to scan this number of files/folders. I personally set the scan interval to 86400 and use the file watcher though.

I would still suggest trying to limit the CPU with GOMAXPROCS, which will likely solve the overheating issue (unless we are talking about single-core devices here, but PinePhone itself has 4 cores).

Yeah, I see the point personally, but until (or unless?) something like this gets implemented into Syncthing, I’m just suggesting utilising the existing options to somewhat work around the problem.

Another way would be to try looking for alternatives to cpulimit with process monitoring, so that the limit would be applied automatically when seeing the process. I know of some solutions for Windows, but my knowledge on Linux is very limited, so I cannot provide any help in this aspect, unfortunately.

The cpulimit problem might be easily solved, by using the -i flag to also limit child processes.

Otherwsie if you are using systemd, there’s cpulimit: https://www.freedesktop.org/software/systemd/man/systemd.exec.html#Process%20Properties

And if not, you can use cgroups directly.

There are solutions, and the nice thing is: If you happen to ever start using a program that uses your cpu efficiently as well, even too efficiently for your taste, you can apply the same solution to those.

It is simple when looking at it from the user perspective. The functionality itself still needs to be implemented in the code, which means that someone needs to do the work. Also, if none of the maintainers is interested in the functionality personally, they will likely not spend their free time working on this.

That’s how the development works, and I have had at least several of my own feature request rejected too. Life goes on, as they say. In many cases it’s not that the functionality itself is unwanted or so, but rather that they may not want a feature request to hang there forever. On the other hand, if someone comes up with a clean pull request implementing this particular functionality, then I doubt that it would be rejected without any consideration.

2 Likes

I’ve a hard time naming a single application which offers a CPU limit to be honest.

4 Likes

@ell1e which folder roots on your phone are set up in Syncthing? Which ignore patterns do you use? Ignoring might help a lot on phones.