Historically, there has never been a limit as such on the number of concurrent read transactions in Syncthing. There may well be code paths holding a lock that then needs to do database operations, and where it will deadlock if someone else is holding a database connection and is waiting for the lock, etc. I don’t recommend trying to use the number of concurrent database connections as some sort of relevant limiter of concurrency.
That’s not about concurrency, that’s all about cache size. With the same memory usage, with 2 connections, compared to 16, we can have x8 larger context cached. It is all about that.
Nonetheless, it’s not a knob that’s really available for that purpose, as you’ve discovered.
sure; however important for me, and I will always work with at least a patch to lower this from 16 to something smaller, increasing page cache. And will report in case you want follow this way some day. The only thing unclear here is that is the magick number “16” here per default. Do you have “safely guaranteed less” concurrency required than “16” in a code, so 16 is guaranteed to work, or with 16 is just “realistically will never happen”, but in reality this is just a probability, and not a guarante…
UPD: maybe like 3 or 4 will also be “guaranteed enough”, given you have like max 3 of different code paths with locks here, for example. I just want to find it out, at least in the practical aspect.
16 is just gut feeling guaranteed to be enough. 2 is pretty much guaranteed to be too little. The actual limit will be somewhere in between probably, I know neither what it is nor how to systematically find & guarantee it under useful circumstances. With leveldb there was no concept of “connections” and never a reason to limit the number of readers.
1 Like