Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Resource hogging with application not responding during file transfers #9439

Closed
cyberduck opened this issue Apr 12, 2016 · 12 comments
Closed

Resource hogging with application not responding during file transfers #9439

cyberduck opened this issue Apr 12, 2016 · 12 comments

Comments

@cyberduck
Copy link
Collaborator

@cyberduck cyberduck commented Apr 12, 2016

72d76fe created the issue

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

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Apr 12, 2016

@dkocher commented

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.

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Apr 12, 2016

@dkocher commented

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

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Apr 12, 2016

72d76fe commented

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.

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Apr 13, 2016

@dkocher commented

#9451 closed as duplicate.

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Apr 13, 2016

@dkocher commented

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

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Apr 13, 2016

@dkocher commented

#9118 closed as duplicate.

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Apr 13, 2016

@dkocher commented

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.

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Apr 13, 2016

@dkocher commented

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

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Apr 15, 2016

@dkocher commented

In 6c56b73.

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Apr 17, 2016

@dkocher commented

Please update to the latest snapshot build available.

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented May 4, 2016

efc67aa commented

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.

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Mar 13, 2017

@dkocher commented

Duplicate for #9878.

@iterate-ch iterate-ch locked as resolved and limited conversation to collaborators Nov 26, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants