Search the Community

Showing results for tags 'cpu load'.

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 5 results

  1. Hello! I really don't know whether I need to present myself because I found nothing about it. Anyway, It's been about one month since the problem I'm facing first occurred. To be specific, I tried two things: I started the Resilio sync client in daemon mode, then I monitored resource consumption and I noticed it occurred while it was adding event listeners to each file. Then, I decided to try updating the client and reinstalling (I just downloaded the archive from the site and re-extracted). By adding one folder at a time, I noticed that when I added a really big folder (in terms of number of files) the problem reoccurred. I hope to get some help and I'm ready to provide all kind of debug information. Thanks in advance, Eugenio.
  2. Dear Sync community, I've posted the issue previously in but im afraid, the following problem still persists: Resilio Sync 2.4.4 (732) is shown as occupying 100% CPU in 'Activity Monitor'. A folder containing ~114.000 of admittedly small files (45 GB) is constantly shown as indexing, even when setting folder_rescan_interval to e.g. 3600. I noticed the constant indexing issue also on a Synology NAS, however setting folder_rescan_interval to 3600 seems to have helped to alleviate the issue a bit here. On the Mac, running the command sudo fs_usage -w -f filesys > fs_usage_resilio.log will produce a ~750 MB log file within 30 seconds when resilio is running (as opposed to 1.6 MB within 30 seconds with resilio turned off). within the logfile the following sequences are repeated seemingly for every synced file: 19:52:03.015920 lstat64 <path-to-some-synced-file> 0.000005 Resilio Sync.1138808 19:52:03.015930 listxattr <path-to-some-synced-file> 0.000009 Resilio Sync.1138808 19:52:03.015935 getxattr <path-to-some-synced-file> 0.000005 Resilio Sync.1138808 19:52:03.016021 open F=53 (R_____) <path-to-some-synced-file> 0.000006 Resilio Sync.1138808 19:52:03.016022 fcntl F=53 <GETPATH> 0.000001 Resilio Sync.1138808 19:52:03.016023 close F=53 0.000002 Resilio Sync.1138808 [...] 19:52:16.106473 lstat64 <path-to-some-synced-folder> 0.000002 Resilio Sync.1138808 19:52:16.106490 write F=6 B=0xa3 0.000003 Resilio Sync.1138593 19:52:16.106491 lseek F=6 O=0x02bfd39d <SEEK_SET> 0.000001 Resilio Sync.1138593 19:52:16.106536 open F=127 (R_____) <path-to-some-synced-folder> 0.000003 Resilio Sync.1138808 19:52:16.106537 fcntl F=127 <GETPATH> 0.000001 Resilio Sync.1138808 19:52:16.106538 close F=127 0.000001 Resilio Sync.1138808 With this behaviour of frequent re-indexing and constant file access it is not feasible to run resilio on that folder permanently without draining the battery. Has anybody else encountered a similar issue on their system? Thank you for your help.
  3. Hello, we deployed BTSync 1.2.91 (i386 linux version) on 4 linux machines, 1 CentOS and 3 NAS TS-269 (linux-based operating system QTS). I noticed that on various occasions CPU load as dislayed by the top utility shows btsync running at the top with high cpu loads over 85%, often peaking to 99.9%. Some machines reached a consistent 99.9% level after about a day. When the porcessed reached 99.9%, GUI responds slowly, some synced folders appear not to be synchronized (at least in GUI) and there seem to be hanging (infinitely pending) transfers. I noticed similar behavior with version 1.2.82, where CentOS process often crashed with segfault and QTS machines as if "accumulated" load until 99.9% when they stopped working, although the process itself did not crash. Temporary solution implemented is periodical restart of btsync every two hours. After restart, btsync starts at low CPU loads (1 to 10%) and is getting busier as time passes. Before it becomes completely dead it is gracefully restarted by a cron job. Could this be answer to some of you guys who reported insanely slow download speeds? Regards, Jindrich Vavruska
  4. I'm using BitTorrent Sync on Linaro Ubuntu running on a Cubietruck (ARM) for quite some time now. I noticed that BTSync uses considerably more CPU lately than it used to. Months ago, it was like 3%@idle. Right now, it's more like 13-20%@idle. Note: idle=devices are connected, but sync is finished BTSync monitors about 9000 files (there used to be more files, like 15000) spread over 11 folders. I'm using the packages "btsync_1.3.1-1_all.deb" and "btsync-common_1.3.105-1_armhf.deb" installed from either """ (which one is newer for apt). The log is quite small (<20k) and mainly consists of "Incoming connection from", like 200 lines. Unfortunately, both PPAs do not provide older versions of BTSync, so I'm unable to downgrade. Is there anyone else experiencing the performance impact on Linux/ARM? What can I do to improve the situation?
  5. On my NAS (Synology DS413) btsync consistently uses between 20 and 50% CPU. This is true for versions from1.3.86 (the first I have) until 1.3.109 (the current version). I have about 25 folders attached to btsync, good for some 30,000 files. I may assume that btsync can handle this easily. The logfile only shows a couple of incoming connections per second. On another system (15 folders, 20,000 files) btsync uses about 2% CPU, which I consider a normal value. Anything I can do to find out what's going wrong?