I’m sorry this will be a long post. I try to include as much information as possible, some probably unnecessary. Bear with me, please.
I’m a long time user of Syncthing. Since the very beginning a (small) QNAP server is one of the clients hosting Synching and albeit not being a very powerful machine has performed admirably. I’ve added more and more folders, and although it sometimes takes hours (and in two cases: days) to build the index, once it is done, everything else runs smoothly. Until this week.
I’ve been bitten by the 14.35-problem (of folders paths being resettet because they don’t have a label) and have tried to recover with 14.36. Unfortunately things just don’t work out. The current problem is, that the index can be built, but as soon as I share that folder with another machine (just one is enough) the ram consumption climbs and climbs, the machine stalls, Syncthing GUI is not responsive anymore and the console log shows messages along these lines:
2017/08/11 21:11:14 http: panic serving [<IPv6 address>]:53867: runtime error: invalid memory address or nil pointer dereference
goroutine 841 [running]:
github.com/syncthing/syncthing/lib/ignore.(*Matcher).Lines(0x0, 0x0, 0x0, 0x0)
github.com/syncthing/syncthing/lib/model.(*Model).GetIgnores(0x10f9c370, 0x12c52f4b, 0xa, 0x13329360, 0x0, 0xd11ff701, 0xe, 0x955f709, 0xae27d0, 0x0, ...)
main.folderSummary(0xa98278, 0x10f5e000, 0xa990d8, 0x10f9c370, 0x12c52f4b, 0xa, 0x152)
main.(*apiService).getDBStatus(0x11c874a0, 0xa94ff8, 0x112eaa20, 0x13dfca00)
main.(*apiService).(main.getDBStatus)-fm(0xa94ff8, 0x112eaa20, 0x13dfca00)
net/http.HandlerFunc.ServeHTTP(0x11cb4268, 0xa94ff8, 0x112eaa20, 0x13dfca00)
net/http.(*ServeMux).ServeHTTP(0x1193dfe0, 0xa94ff8, 0x112eaa20, 0x13dfca00)
main.getPostHandler.func1(0xa94ff8, 0x112eaa20, 0x13dfca00)
net/http.HandlerFunc.ServeHTTP(0x10f8e0a0, 0xa94ff8, 0x112eaa20, 0x13dfca00)
main.metricsMiddleware.func1(0xa94ff8, 0x112eaa20, 0x13dfca00)
Some additional info:
The machine usually syncs about 12 folders, with a total of 124055 files, 10355 folders and ~1940G.
Since the indexing will take days, I’ve adopted the following routine:
- all folders are paused
- no folder is shared
- all sync partners are paused as well
One folder is unpaused. I wait until the indexing is finished and the folder is Unshared. Then I unpause the appropriate sync partner and share the folder with this partner.
If that has finished, I pause the sync partner, pause the folder and continue with the next.
That way there is always just one folder and one sync partner at the max.
In the past, this has worked. This week, it fails.
When the QNAP starts indexing a folder with 591 files, 50 folders and 553GB content, it uses up to 380MB RAM. Since the small QNAP has only 512MB, it is on its limit.
While this happens, the sync partner outputs this on the console log every few minutes:
21:04:17 INFO: Established secure connection to XXXXX-YYYYY-... at 192.168.254.21:22000-192.168.254.4:43522 (tcp-server) (TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305)
21:04:17 INFO: Device XXXXX-YYYYY-... client is "syncthing v0.14.36" named "DE71364-SV-U4"
21:11:03 INFO: Connection to XXXXX-YYYYY-... closed: reading length: EOF
There is another machine which has the duplicate of this machine (but different hardware platform). While running with all folders active and 6 sync partners it consumes approx. 70MB RAM.
Could the reason for my problem be too little RAM?
I’m by no means a programmer, so please excuse if that is plain wrong. I’m just guessing here. Maybe somebody with more knowledge could help me out and explain what I’m seeing here. Is there something I can do to avoid this?
Thanks for reading this far! Much appreciated.