From The list of syncing files it seems there are only two pullers.
I have alot of small files and it is a very slow transfer even though the 2 peers have a direct LAN connection and are very powerful servers.
You now want PullerMaxPendingKiB which is the max number of kibibytes in flight. Multiply by about 16 megs per old style puller thread to get a new starting point. The new default is 32 megs, iirc.
If you have a total of fifteen files comprising only a handful of bytes no puller setting will have any measurable effect. I also have a hard time imagining the sync would be slow due to this.
That’s a lot of small files, so you’re probably limited by disk sync writes (database and syncing each completed file). As mentioned in the previous thread, try increasing copiers to handle more files in parallel - more blocks in parallel doesn’t help when the average file just consists of a single block or two.
But if those are spinning disks, the relevant limits are synchronous write operations per second, and each of those are really slow. Network bandwidth etc won’t even factor into it.
Default is two, I’d start with something like the number of disks in your array. Yeah, this is all on the receiving (“pulling”) side.
But if the RAID is a “stupid” RAID (i.e., hardware RAID controller or NAS as opposed to something like ZFS or NetApp) our disk flushes will probably result in the raid controller flushing the cache on/to all disks, which will hurt performance like hell. So, many small files => slow sync, probably.
The small files still do little to the overall progress percentage, but i can see that now many files are beeing processed in parallell. This should speed things up.
To see some more progress i also changed download order from random to largest first.