I have a low RAM VPS (500M), but one syncthing instance has already eaten up almost 200M RAM. I want to serve multiple users with separated repository though. I understand that I have to run multiple syncthing instances; is there a way to limit the total RAM usage?
No, not really, it needs what it needs. The GUI drives up the usage though, so not having that up will calm things down a bit.
Ok I see your point here; but is it possible to alternate the instances – so they won’t eat memory at the same moment?
I don’t think its possible, just enable swap, or have a single instance serving multiple folders/repos which should have less usage compared to multiple instances.
This could be a good use case for Docker containers. Put each instance in a container and set the CPU and memory limits with the appropriate ‘docker run’ flags.
Dockerfile here: https://github.com/firecat53/dockerfiles/tree/master/syncthing
No guarantees though… Big repositories just need enough RAM!
Or just use cgroups if you are running a recent linux kernel, which is what docker uses internally, no need to have a whole OS image for running syncthing.
At least if you’re using version .11 you can use the GOGC (go garbage collection) variable, (from 1 to 100%) e.g. GOGC=20 ./syncthing
If you want to allow different users to have different sets of folders on the pi, and to adminster them themselves, then yes, you need separate instances.
If you want the pi to synchronize folders from multiple people, but you only want a dedicated trusted administrator (i.e. you) to be able to control which folders are synchronized with whom, then you can easily do that with a single Syncthing instance.
Thanks! That’s some useful information.
My containers come with GOGC and cgroups. You can easily change the user and config dirs. And there are arm versions (rpi). And they’re really tiny space-wise because they’re based on a scratch image:
(Sorry for the necrobump. But I think this post is useful reference - if users need to configure low resource use. This is the only discussion which actually focusses on configuration, not bugs or architecture.) (Very welcome, xuhdev.)