Cyberduck Mountain Duck CLI

#9439 closed defect (duplicate)

Resource hogging with application not responding during file transfers

Reported by: jimgoldstein Owned by: dkocher
Priority: normal Milestone: 5.4
Component: core Version: Nightly Build
Severity: normal Keywords:
Cc: Architecture:
Platform:

Description

Currently Cyberduck is a huge resource hog on my uploads. I'm a Backblaze employee and doing this from our office where we have ample bandwidth on our network. Attached are screenshots on the memory being allocated to Cyberduck (60GB... note my laptop has 16GB RAM) and with regular CPU usage of 350-467 %CPU. I'm at the point that it looks like the memory required to run Chrome and Cyberduck concurrently is causing problems. I've got it down to a 1 window margin where the application freezes if I open one more tab and works again when I close a tab.

Not sure what is causing the problem but you'll want to look into it.

Thanks

Jim

Attachments (1)

resource_hog.zip (1.2 MB) - added by jimgoldstein on Apr 11, 2016 at 10:52:50 PM.
Resource hog screenshots

Download all attachments as: .zip

Change History (18)

Changed on Apr 11, 2016 at 10:52:50 PM by jimgoldstein

Resource hog screenshots

comment:1 Changed on Apr 12, 2016 at 7:00:54 AM by dkocher

With two transfers and the transfer concurrency set to 9 you will have 18 threads running for uploads. Please try to set a lower value for the number of connections allowed for transfers to lower CPU usage.

comment:2 Changed on Apr 12, 2016 at 7:01:54 AM by dkocher

We also have #9118 which reports high memory usage outside of our embedded runtime.

comment:3 Changed on Apr 12, 2016 at 7:02:15 AM by dkocher

  • Summary changed from Resource Hogging Causing Crashes / App Not Responding to Resource hogging with application not responding during file transfers

comment:4 Changed on Apr 12, 2016 at 6:40:19 PM by jimgoldstein

Even reducing the threads this is happening. The longer the app is open as transfers happen the more the memory allocation grows and grows. I'm trying an upload this morning and the app memory allocation quickly skyrockets even after an upload fails. Trying the upload again the memory allocation continues to grow. My upload is now at 41GB in memory allocated. Based on past experience when it hits 60GB on my machine it will crash it.

Still a serious problem.

comment:5 Changed on Apr 13, 2016 at 1:13:35 PM by dkocher

#9451 closed as duplicate.

comment:6 Changed on Apr 13, 2016 at 1:14:28 PM by dkocher

  • Milestone set to 5.0
  • Owner set to dkocher
  • Status changed from new to assigned

comment:7 Changed on Apr 13, 2016 at 1:19:02 PM by dkocher

We think we isolated the cause of this to be accessing security scoped bookmarks of files.

comment:8 Changed on Apr 13, 2016 at 1:44:13 PM by dkocher

#9118 closed as duplicate.

comment:9 Changed on Apr 13, 2016 at 8:49:10 PM by dkocher

We could pin this down that this is not an issue when running in a sandbox. Somehow when requesting security scoped bookmarks and not running within an application sandbox is leading to this massive memory leak. Thus, the Mac App Store version should not be affected from this.

comment:10 Changed on Apr 13, 2016 at 9:04:40 PM by dkocher

We are just pushing a new snapshot build that will have sandbox entitlements set as a workaround.

comment:11 Changed on Apr 15, 2016 at 9:40:17 AM by dkocher

  • Milestone changed from 5.0 to 4.9.1

comment:13 Changed on Apr 15, 2016 at 11:39:46 AM by dkocher

  • Resolution set to fixed
  • Status changed from assigned to closed

comment:14 Changed on Apr 17, 2016 at 6:06:22 PM by dkocher

Please update to the latest snapshot build available.

comment:15 Changed on May 4, 2016 at 10:24:53 AM by siclemat

I also suffer from memory hogs (I have 84 bookmarks) on MacOS a long time now. Installing the latest snapshot didn't cure anything. Just opening CyberDuck without any connections alive, uses more than 1.1GB of memory.

comment:16 Changed on Mar 13, 2017 at 12:45:53 PM by dkocher

  • Resolution fixed deleted
  • Status changed from closed to reopened

Duplicate for #9878.

comment:17 Changed on Mar 13, 2017 at 12:46:02 PM by dkocher

  • Milestone changed from 4.9.1 to 5.4
  • Resolution set to duplicate
  • Status changed from reopened to closed
Note: See TracTickets for help on using tickets.
swiss made software