@jorgen_k, where exactly did you change that? On ARM device only, or on all devices in the cloud?
On all devices in my cluster.
I think it is like this, Machine A is slow. Machine B emits a ping to machine A, that times out. Machine B reconnects, and Machine A do a full rescan of everythinig. This starts over and overā¦ I have no evidence, but changing the timeout on all members made it.
You change it easiest in the web gui, under Advanced then Options, or by editing the config.xml.
Unfortunately bolt-build still canāt finish properly.
Started single ARM instance, with no other devices in cloud, no WebGUI, just indexing. Again got fatal error: fault. And boltdb size again = 2048Mb.
panic-20150808-220817.log (34.7 KB)
Switching to release on leveldb. Will try āisolatedā indexing on it.
I have the same NAS and had the same problems. Changing the timeouts helped a lot - in terms of actually syncing anything at all now! 
The CPU usage is still usually ~97% and it takes some time to catch up with the other boxes, but iām using it as backup storage only, so itās not all bad.
I think the initial sync took closer to a week than hours/days, even with most of the data already being on there (i used BT Sync before), so the hashing and DB I/O seems to be the main issue on that device.
(~400.000 files, 1.4TB)
I saw the same thing on my Raspberry Pi 2, the CPU usage is very problematic and delays syncing operations at startup and after devices connection.
In my case, it takes 20 minutes to return to normal operation. (~20 000 files, >10GB)
First, I added these two parameters in my config.xml : pingTimeoutS = 600 pingIdleTimeS = 1200
I solved the ping timeout but the synchronization takes times to begin after devices connection.
Iāve tried CPU profiling and the following documents can be found here :