Search the Community

Showing results for tags 'performance'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Resilio Sync
    • Sync General Discussion
    • Sync Troubleshooting
    • Sync for NAS (Network Attached Storage)
    • Sync Stories
    • Developers
    • Feature Requests

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start





Website URL







Found 13 results

  1. My systems are suffering from Major performance- and sync-problems! I've got 2 macOS systems and 2 NASses running first on 2.5.4 and now on 2.5.5 (just upgraded today). The App in macOS just stalls system; Activity monitor gives a lot of times; CPU over 100% and Not Responding. systems have problem with syncing with each other. Arch Linux NAS on my office has been offline for days but is actually running. Now in the office it syncs. Webpage of both Linux systems are terribly slow for a while and then they are fine and back again. This is output of Arch Linux system after restarting; * rslsync.service - Resilio Sync per-user service Loaded: loaded (/usr/lib/systemd/user/rslsync.service; enabled; vendor preset: enabled) Active: active (running) since Sat 2017-07-08 16:14:49 CEST; 19min ago Main PID: 280 (rslsync) CGroup: /user.slice/user-1000.slice/user@1000.service/rslsync.service `-280 /usr/bin/rslsync --nodaemon --config /home/raymond/.config/rslsync/rslsync.conf Jul 08 16:34:31 nas rslsync[280]: [20170708 16:34:31.456] D! 21ReverseHTTPConnection::set_error[0x00007f89e6969270][56] 103 (EOF) Jul 08 16:34:31 nas rslsync[280]: [20170708 16:34:31.458] D! 21ReverseHTTPConnection::set_error[0x00007f89e6c3cd60][67] 103 (EOF) Jul 08 16:34:31 nas rslsync[280]: [20170708 16:34:31.463] D! 21ReverseHTTPConnection::set_error[0x00007f89e6c3cd60][55] 103 (EOF) Jul 08 16:34:31 nas rslsync[280]: [20170708 16:34:31.483] D! 17TrackerConnection::set_error[0x00007f89e69877a0][16] 104 (Connectio Jul 08 16:34:31 nas rslsync[280]: [20170708 16:34:31.483] D! 17TrackerConnection::set_error[0x00007f89e697a5f0][17] 104 (Connectio Jul 08 16:34:31 nas rslsync[280]: [20170708 16:34:31.484] D! 17TrackerConnection::set_error[0x00007f89e69648f0][116] 104 (Connecti Jul 08 16:34:31 nas rslsync[280]: [20170708 16:34:31.538] D! 21ReverseHTTPConnection::set_error[0x00007f89e6c04cd0][16] 103 (EOF) Jul 08 16:34:31 nas rslsync[280]: [20170708 16:34:31.538] D! 21ReverseHTTPConnection::set_error[0x00007f89e6c050c0][17] 103 (EOF) Jul 08 16:34:31 nas rslsync[280]: [20170708 16:34:31.920] D! 21ReverseHTTPConnection::set_error[0x00007f89e6c3cd60][56] 103 (EOF) Jul 08 16:34:31 nas rslsync[280]: [20170708 16:34:31.925] ZIP: Can't locate [css/style.css] in zip, error -100. and after a while; * rslsync.service - Resilio Sync per-user service Loaded: loaded (/usr/lib/systemd/user/rslsync.service; enabled; vendor preset: enabled) Active: active (running) since Sat 2017-07-08 16:39:06 CEST; 1h 31min ago Main PID: 444 (rslsync) CGroup: /user.slice/user-1000.slice/user@1000.service/rslsync.service `-444 /usr/bin/rslsync --nodaemon --config /home/raymond/.config/rslsync/rslsync.conf Jul 08 18:10:10 nas rslsync[444]: [20170708 18:10:10.361] D! 10SyncTcpReq[0x00007f1d4d634400]: EOF - error: 103 (application protocol level timeout) Jul 08 18:10:10 nas rslsync[444]: [20170708 18:10:10.361] D! 10SyncTcpReq::set_error[0x00007f1d4d634780][-1] 103 (application protocol level timeout) Jul 08 18:10:10 nas rslsync[444]: [20170708 18:10:10.361] D! 10SyncTcpReq[0x00007f1d4d634780]: EOF - error: 103 (application protocol level timeout) Jul 08 18:10:10 nas rslsync[444]: [20170708 18:10:10.361] D! 10SyncTcpReq::set_error[0x00007f1d4ea9d5e0][-1] 103 (application protocol level timeout) Jul 08 18:10:10 nas rslsync[444]: [20170708 18:10:10.361] D! 10SyncTcpReq[0x00007f1d4ea9d5e0]: EOF - error: 103 (application protocol level timeout) Jul 08 18:10:10 nas rslsync[444]: [20170708 18:10:10.562] D! 10SyncTcpReq[0x00007f1d4ea9d8a0]: EOF - error: 0 (Success) Jul 08 18:10:11 nas rslsync[444]: [20170708 18:10:11.952] D! 10SyncTcpReq[0x00007f1d4d1047a0]: EOF - error: 0 (Success) Jul 08 18:10:12 nas rslsync[444]: [20170708 18:10:12.240] D! 21ReverseHTTPConnection::set_error[0x00007f1d4d1434b0][86] 103 (EOF) Jul 08 18:10:12 nas rslsync[444]: [20170708 18:10:12.343] D! 10SyncTcpReq::set_error[0x00007f1d4c401aa0][-1] 103 (application protocol level timeout) Jul 08 18:10:12 nas rslsync[444]: [20170708 18:10:12.343] D! 10SyncTcpReq[0x00007f1d4c401aa0]: EOF - error: 103 (application protocol level timeout) I'm so annoyed this is my third major problem with Btsync/ Resilio on about 3 years.
  2. Hello again, I'm looking for they way to make some performance test of syncing files between my two machines. As I can see it makes shadow copy and logs doesn't contain all needed timings. Also it sync whole directory, but I'd like to sync some files, however maybe it's available in paid version? It will be better to make those test using linux cli So, the question is: "Do you have some ways to make performance tests using some files or share best practice for this"?
  3. Hi, im a long-time user of btsync, and more or less satisfied. I basically replaced googledrive, dropbox, onedrive and all the others with my btsync network. YEAH! Thats a success. Now, the big it companies merely now where i am on the internet, but not what i store. Thats awesome. BUT on my low-end devices, btsync is a memory hog and a cpu cycle eater. That is (as i now realized while reading the performance tips that are floating around) because I store all my nitty gritty little files in sync (all the files that otherwise would be in some big brother cloud). E.g. on the one low-end device which really gives me an headache currently, i have one share that contains my digital library with 4 GB hdd, 80k files and 2k directories. The performance of the device (intel atom dual core w/ win8pro and 2gb ram) seems strongly correlated with the number of files that are synced by btsync. For my "high-end" hardware, i dont complain. but for the low-end hardware, performance is getting more and more unbearable. Thats why i ask: @all: What is your strategy coping with this problem? @resilio: Is there a road map for tackeling that problem? If yes, please share it with me/us. If no, please share with us/me how we can get rid of this problem, e.g. tell me which alternative service provides a sync for lots of small files.
  4. Hi, I have very often high cpu load on my both macs (mac mini and macbook pro). There are no syncing processes running (no uploads, no downloads and no indexing). One core is at 100% for a long time. Version 2.3.10022 (0) Best regards Kay
  5. Hi, i've installed BTSync on my Synology and on two Macs to sync around 100k files in about 25 GB (lots of JPG and RAW files and a Lightroom database). So far it works… but… The Mac-Client – on is a MacBook Pro – is doing an 'indexing' every 10 Minutes. Every 'indexing' takes a few minutes where BTSync is consuming up to 100% CPU. I've searched a bit and read some longer threads about this indexing-feature but i think i didn't really get it: - Indexing is building a catalogue of all files that i like to sync to detect new/deleted files? - But then, changes made on one mac are transferred to the NAS in nearly realtime… not every 10 Minutes… And if i wake up my MacBook, the files are downloaded from the NAS nearly instant … not after 10 Minutes So again - what is the purpose of creating an index every 10 Minutes? Are there save ways to optimize the clients behavior? I like to have my Lightroom-Files in sync on both Macs and i'm using a NAS because both Macs are not running at the same time. Both Macs are creating/deleting files (JPG-Previews etc.). The NAS is running 24/7 so the 'truth' should always be on that NAS… In this case: Is it save to say, that i don't need to build an index on the macs every 10 Minutes but for example only once a day? I mean: If i'm working on the local iMac, changes are synced to the NAS in real-time. If i'm working on the MacBook it's the same when i'm at home. Only if i'm working on the MacBook while i'm traveling i need to be sure, that the MacBook will sync all new/changed files to the NAS when i'm back home - While BTSync is running, it should know those changes in realtime, right? So - Why do i need such index in my use case? Is it save to turn it off or set it a way longer interval (once every 10 hours or so) on the mac-clients? Could i even change the interval on the NAS (or turn it off completely) to let the HDDs sleep again from time to time? Thanks a lot for your help to clarify this topic
  6. I'm trying to design a distribution system with the following requirements : the content to distribute would be a directory tree (around one hundred files or maybe one thousand in the whole tree) on a single server which can be modified at will by administrators (adding, replacing, moving files mostly),modifications of the directory tree will be done in batches (several files modified at the same time) and days or weeks will pass between them,the content will be public domain or using a creative commons licence (to be determined),it will be read-only for the clients,the content should be distributed to smartphones in Africa, most of them with very irregular Internet access.(days or weeks without access is possible and might be common place).I'm thinking of using Bittorrent Sync in this context (publishing a read-only code generated by BTSync and letting users configure their local BTSync with it) but I'm not sure if it was designed for many targets (hundreds or thousands of smarphones could be syncing at the same time and maybe more in the future). Is there any limitation in Bittorrent Sync that would prevent using it with this many clients? In Africa, more and more people own Android smartphones but historically this was a market dominated by Blackberry, is there a Blackberry BTsync client planned? I've seen posts about running the Android version on Blackberry but I'm unsure if this is feasible on old Blackberry models as I know very little about this platform...
  7. I have been using BitTorrent Sync for a while. I've tried many different cloud backup solutions (including several other peer-to-peer backup tools) and finally choose BitTorrent Sync and Dropbox as my cloud backup solutions. Generally speaking, BitTorrent Sync is fast once it starts to synchronize. However, I found quite often that BitTorrent Sync waits for a long time (about 5 to 6 minutes) to start synchronization. As BitTorrent Sync has no reliable way to show synchronization progress on Linux (don't trust the web UI) currently, it is very annoying for me as I constently use multiple computers at the same time. To address this issue, I even wrote a bash script to test whether a local file has been synchronized with the remote one. Dropbox on the contrast is much better on real-time synchronization. Changes on files in the Dropbox folder is almost immediately captured. I wonder whether BitTorrent Sync can do a better job to detect changes faster? Perhaps cache freqently changed files?
  8. Hi, I’m a member of a very small btsync network (4 clients) where the most of us use btsync ARM 1.3.94 on Synology NAS or Raspberry Pi platform. We have to synchronize large data files and discovered a suboptimal behavior of btsync regarding performance which can be easily reproduced: Imagine you have 3 clients A, B and C where A is able to see B but not C. B can see both others clients. This can be a situation where A is a system in the internet, B in a local network WITH access to the internet but C is a client in the same local network but WITHOUT access to the internet and only able to see B, so the test configuration is: A <-> B <-> C The upload rate A -> B is SMALLER (this is important!) than the upload rate B->C. When client A starts to synchronize a very large data file with B but C is still offline then there will be with growing time more and more data on B which will be synchronized with C once it is started. If C is now started and it empties the amount of data on B to be transferred to C by the high upload rate from B->C BEFORE A has finished its upload to B then any new data on B WILL NOT be transferred to C until the upload from A to B has ended or the btsync client on C was restarted. In other words while the transfer of data from A to B there is no continuous data transfer between B and C once the client C thinks it is in synchronal state with B by no new data. C has to wait until the upload to B has finished before it gets new data … which is of course not very efficient. The upper configuration is just to express a simple environment; the issue also happens if all clients are connected via internet connection but a receiving machine has higher upload to the others in the network than the link between the first sender and this receiving client.
  9. Hi, can some of you explain to me how a btsync client decides what upload bandwidth will be used to the other members sharing the same secret? Background: When my team (consisting of 5 clients) shares data over the internet we can see at the seeder client, the system with the lowest upload bandwidth gets the most bandwidth from the seeder. "iftop" is a nice tool to check this on a Linux client. We have here the effect while transferring large data files that the clients with the smallest upload capability get ready first and the systems with largest possible upload bandwidth finish at last and this in a strict order! This is obviously the wrong order since it would be of course optimal to fill the client with the highest upload capability first so this resource can be fully used while distributing the data instead of waiting for the clients with the smallest capability to upload data to the others. But perhaps this simply bases on the understanding of the algorithm used and can be influenced somehow, so that's why I'm asking this question, here. Greetings from Germany
  10. hello, I setup btsync on my rapsberrypi model B, added some overclocking, serving as one way backup server with external disk. Unfortunately btsync is eating all my cpu, even during time there is nothing to sycnhronize. I know raspberry is not very strong machine, however I wouldn't expect so bad performance with btsync. I read the manual and set all the properties refering somehow to performance. I even tried to send logs to /dev/null to prevent btsync write on sdcard too often. But nothing really helped. Using btsync 1.2.82 from AUR. Here is the config file and service script: /usr/bin/btsync --config /home/pi/.config/btsync/btsync.conf --nodaemon "storage_path" : "/mnt/backup/.btsyncStorage", "check_for_updates" : false, "use_upnp" : false, // use UPnP for port mapping "disk_low_priority": true, "lan_encrypt_data": false, "folder_rescan_interval": 1800, "lan_use_tcp": true,
  11. BTsync is drawing quite a lot of CPU resources from my Raspberry Pi (currently I have approx. 97k files that total 15GB and I expect that to double before it plateaus). Based on other articles in this forum, i'm considering to increase the folder_rescan_interval to be a much higher number. Here comes my question ... The Raspberry Pi simply serves as a Read-Only device, in other words, no files will be changing on this device, it only servers to mirror a folder contents on another (ubuntu) device that frequently creates new files (photos). In this scenario, is folder rescan even necessary on the Raspberry Pi? If not, how do I disable rescanning, simply set folder_rescan_interval to a very large number?
  12. My bad. My supplier f#*& me.. Tried to delete this question. couldn't.
  13. Hello and congrats on the fantastic use of the Bit Torrent technology... Really really cool and very easy to use. I have a question about performance. If I have a directory with 5 subdirectories inside that I want to share but it is quite large... beyond the benefit of being able to share subdirectories with different people is there any performance penalty in configuring 5 separate (sub)folders rather then the single top level folder? In other words is it better to spread synchronization across 5 folders or is it better to have 1 VERY large folder to sync. Thank you Chris