Hi, I am observing heavy RAM usage on two of my computers running Syncthing. (See screenshots).
Any thoughts?
syncthing-heap-linux-amd64-v1.2.2-000333.pprof (369.5 KB)
syncthing-cpu-linux-amd64-v1.2.2-000238.pprof (851 Bytes)
where do you figure the lots of ram? your syncthing gui itself shows 293megabytes. hardly lots of on todays mainstream pc like machines. also your console gui tool shows you have 16gigs of ram and only 3.5 gigs ram eaten.
what are your worries? you are sharing 895gigs of data. the ram amount for that according to your gui is below 300megabytes.
1 Like
Hi, thank you for your answer. I might have not expressed myself correctly. I am sorry.
VIRT stands for the virtual size of a process, which is the sum of memory it is actually using, memory it has mapped into itself (for instance the video card’s RAM for the X server), files on disk that have been mapped into it (most notably shared libraries), and memory shared with other processes. VIRT represents how much memory the program is able to access at the present moment.
The syncthing process occupies more than 21GB of memory which also leads to the swapping which you can see on my screenshot.
My questions:
- Why does it need to much memory?
- What can I do about this?
- Why is it telling the End-User, it needs 300mb, if it actually uses 20GB?
Virtual memory is virtual, it’s not real, it’s not using 21GB. https://golang.org/doc/faq#Why_does_my_Go_process_use_so_much_virtual_memory
Resident memory is 1.5GB in the screenshot.
Also, your top screenshot clearly shows there is nothing using 21GB of memory.
It’s also good to know that Linux effectively misreports this. While the figure is true in a technical sense, it’s true only because the RAM is not currently needed for anything else. If it were, most of it is free to be reclaimed by the OS and used for other things. The actual in use bit is very close to the 300 MB self-reported by Syncthing.
Accounting in virtual memory systems is tricky.
2 Likes
Thanks everyone. However, this still does not really answer my questions. I am aware of the memory concepts in operating systems. My question was, why sync thing is eating ALL available memory, claiming it as virtual. I mean, why would you do that, if you only need 300 megabyte. I do not have seen many processes with this behavior.
Since everyone here is signaling me, that this is all very normal? Can you guys confirm, that you see the same thing in your syncthing?
Yes, it’s normal. Virtual memory is virtual. It’s just a convenient fiction for the garbage collector.
https://golang.org/doc/faq#Why_does_my_Go_process_use_so_much_virtual_memory
1 Like
The large amount of cache memory can be a result of high disk I/O in syncthing.
Syncthing itself doesn’t use much memory, as you can see it’s only about ~300 Megabytes. However, syncthing reads lot’s of files. Those files must be loaded into memory in order to read them. After syncthing is done reading files, the operating system may release the ressources, but if the memory is currently not needed for something else many OS’es keep the files around in memory in case someone else needs them again - this can make up a large amount of the cache memory that htop shows you in yellow - this is memory that is not actually in use and can be re-used anytime.
You’re seeing some swapping, not because there is no memory available, but because the linux kernel offloaded some of the pages which were not used for a long time, in order to not having to release cache memory. This may sound strange to the user (“why prefer swapping if you could just free up cache instead”), but it’s just the way memory management works in most operating systems.
Windows does this all the time, it even swaps dozens of gigabytes when you only have 3 Gigs of physical memory in use. Linux is not that aggressive, but it also prefers swapping a long-unused page over freeing cache memory.
General guidline: Only the green amount of memory in htop matters. The yellow thing can be ignored entirely.
Virtual memory is not that, you are talking about page cache which is not accounted under the process memory but kernel memory.
@lukas yes, all go applications look like this, and again, it’s not actual memory used, it just signifies the range of addresses go process has access to, in case it asks.
1 Like
Yes that’s correct, but it does show up in (h)top/free, which was also shown above. It’s also a likely cause for swapping. That’s what I was referring to.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.