Syncthing 2.0.2 first scan extremely slow

Support
1

Hello,

I just migrated one windows machine from 1.30 to 2.02

This machine is sharing a 1.5TB folder with a NAS on the same LAN (receive only).

As syncthing was installed in synctrayzor v1, I took the opportunity to uninstall everything. So I did not run the db migration: I reinstalled syncthing 2.0, restored the config files and let the service do the first scan by itself. This is not the first time I use this strategy, as in the past I occasionally had issues with the db, and the simplest fix was to nuke the db and restart with a “first scan”, which was generally complete overnight.

However now it seems to take forever (the expected time is currently 5 days).

Is this expected?

Is there any config setting to speed this up?

Note that the computer is not doing anything else, syncthing uses only 3-5% of CPU. in particular, nobody is touching the files, neither on the PC nor on the NAS.

TIA -MH

2

I have the same feeling. It is much much slower than previous syncthing version. I did exactly the same - instead of hoping that migration works I started everything from scratch. And as you I did it few times in the past to solve some issues.

It is not very scientific as I do not have exact measurements but it is noticeably slower.

3

What is your storage type? Is the database located on an SSD or an HDD?

I’ve been running Syncthing v2 on many devices since the beginning of its development, including very weak hardware, but for me performance-wise it seems at least on par with the v1 line, if not faster. This is all on SSDs or other types of flash storage though.

4

Support bundles might clarify.

5

both the db and the files are on a very large traditional drive (internal). but irrespective of the actual setup, what I’m saying is that syncthing 1.x used to be able to complete the first boot roughly overnight, while 2.x looks about 6-7 times slower.

note also that the folder contains ~50% large files and ~50% very small (think large=20Mb and small=1Kb), and since hashing small files may be slower, maybe it’s just the prediction that is wrong.

Let me just add that I see

2025/08/18 12:26:31 INFO: syncthing v1.30.0 "Gold Grasshopper" (go1.24.4 windows-amd64) builder@github.syncthing.net 2025-06-20 09:17:23 UTC

2025/08/18 12:26:32 INFO: Hashing performance is 282.05 MB/s

2025-08-18 14:09:21 INF Measured hashing performance (perf="324.05 MB/s" log.pkg=syncthing)

from what I see, this hashing speed is a bit variable but consistent, so this doesn’t look like the source of the problem.

and still, I see “scan time remaining” going wildly up and down between 2 days and 5 days.

6

Yeah, I haven’t done any actual benchmarks, but I do feel that the v2 database is heavier on the storage side, and if the storage is slow, you will experience bottlenecks.

7

I never said my disk is slow, I said it’s a spinning disk :wink:

Update: syncthing 2 is definitely much slower, it’s not just the prediction.

The local state is currently about 0.5TB (so 1/3 of the total); the estimated time left continuously varies between 2d and 30d more or less randomly… I’m likely going back to 1.3, unless someone tells me there is a workaround

p.s.: the new database at the moment has the same size that the previous had after all the sync was done. Is this also expected?

8

I suppose it’s all relative. :grinning_face:

What make/model of spinning disk?

9

For slow 2.0 instances it might also be relevant to know where the database is located (i.e. on an HDD or SSD? on the same HDD as the files or another?)

As for myself, I have no issues whatsoever on my MacBook (M1 Max) nor any of the iOS devices I test with. I do have a Synology RS422+ NAS that slowed down badly with 2.0. It doesn’t seem to be related to CPU usage, swapping or memory usage, just slow I/O (scanner activity seems to be blocking the database?). Both the database as well as the files themselves are on rather slow HDDs (the database is on a mirror volume). I will be changing those out later for a faster HDD (for the files) as well as an SSD (for the database) and will report back whether that improves things.

1 Like
11

Another update. yesterday at about 10pm I reverted syncthing.exe to 1.30 and it completed the sync in 7h 15m (taken from the log). As I said previously, “completed the sync” means that no file was transferred, just the db was recreated.

I randomly looked at the screen in the first hour and the prediction of time left was always correct in order of magnitude (and not wildly oscillating between 2d and 2years…), I think it started at 10hrs left.

For the curious, the drive is a seagate barracuda 2tb, 5400rpm.

Final note: when I stopped syncthing2.02, the db size was 1.2GB and sync was ~ 30% done. syncthing1.30 final db is 560MB.

12

Is everything located on this single drive? :face_with_peeking_eye: The new database is seemingly heavier on the storage side, so you’re not going to have a good experience if that is the case, especially as the drive in question is one the very slow side (i.e. we’re not talking about 15,000 rpm hard drives here).

We’ve always recommended keeping the database on an SSD, or at least on a separate drive, as otherwise the spinning disk will get boggled down with constant reading and writing at the same time.

13

@m.holmes please create a profling/support bundle to see where the Go code is burning memory/CPU. Not sure if it is possible with release builds to profile SQlite itself and not the Golang wrapper. See Creating a Support Bundle — Kastelo Docs documentation for tutorial. Its mentioned in documentation here Profiling — Syncthing documentation and here Debug Endpoints — Syncthing documentation

@m.holmes Could you specify the hardware setup in a little more detail ? Is disk direct connected or via a converter like USB - Sata or directly to SATA? USB can fluctuate in transfer speed much more then SATA controller (somebody correct me if i’m wrong).

1 Like
15

Since this is 2.0, skip the “Enable Debugging” part.

1 Like
16

Given the available info above, you’re very likely looking at real world average throughput of around 125 MB/s (less than half of Syncthing’s 282.05 MB/s hashing performance on your Windows machine).

And with your Syncthing database on the same drive as the files being hashed, it’s a whole lot of disk thrashing. As others have already mentioned, separating Syncthing’s database from the files being synced is ideal, especially for large volumes.

You mentioned one of the folders being synced is 1.5TB, which is almost 80% of the available storage. Short term, it’d be worthwhile to check if the filesystem needs defragmenting.

Also consider if the current allocation/block size is a good fit (I’m guessing the 2TB drive has a NTFS volume). If it’s too small, when combined with large files, results in more drive head movements on a HDD.

17

I’m condensing a cumulative reply here, sorry if I miss some points

  1. I think I mentioned the drive is an internal SATA drive. it’s NTFS and it’s sufficiently defragmented. also -let me restate- all the files are already in place, so there is no write to the disk except to the db

  2. under the same conditions, syncthing1 is an order of magnitude faster and less erratic in predicting the time left, so irrespective of whether the disk is decent/old/appropriate/etc, I think there is a software regression.

  3. about the setup (which is the same for v.130 and v.202), the only information I didn’t mention is that this drive is not the only drive in the machine: drive C is an SSD, syncthing.exe is installed on C, its db folder is on D and the files to be synced are also on D. the “hashing performance 300MB/s” might come from either C (which would be practically wrong) or D. however, I would bet it’s not really relevant, as it’s the same for v.130 and v.202

  4. this computer is my workstation -not a dedicated server- so usually it’s being used by me. the disk is perfectly acceptable in performance in daily usage. however, I cannot keep the machine down forever to experiment, I will most definitely retry installing v.20x in the future but not right now. Anyway, if anyone wants to investigate, it should not be hard to replicate the experiment.

  5. one point that was unanswered in the thread is about the db size.

when I stopped syncthing2.02, the db size was 1.2GB and sync was ~ 30% done. syncthing1.30 final db is 560MB.

any specific comment on this?

18

There’s no real need to evaluate anything further then: You need to move the DB onto the SSD for decent performance. Anything else you’ll do will pale in comparison for this change. And that’s true in version 1 and 2. I understand that this is a regression for you, but rest assured there are reasons the change was made (and it wasn’t performance).

The new DB is known to use more space. It is also known to grow under heavy write load and shrinking later.

1 Like
19

I have made the exact same experience. On devices with SSD/flash storage there are no issues. Even under Android. On my server with the DB and data being scanned on the same HDD the scans and also the synchronization was notably slower. So I investigated the situation and noticed that one of my HDDs was in progress of dying. This was not the one with the Syncthing DB and also only one Syncthing folder was on it. So the brokenness was not the reason for the slow speeds. However, it meant that I needed to replace the HDD as fast as possible of course. So I replaced both of my HDDs and with my new SSD + HDD setup everything is quite fast again - despite the server still being quite slow CPU-wise. It really makes a difference when the Syncthing DB is on a fast SSD or at least not on the same slow HDD than the data to be synced/scanned (even if many Syncthing folders are still on an HDD).

This sounds interesting. I guess I’ll check that out myself, too.

Under Linux I’d just systemctl edit the Syncthing unit so no other apps are affected.

3 Likes
20

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.