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

Cozy Desktop eating all standby memory on Windows #1216

Open
aleroyer opened this issue Oct 19, 2018 · 4 comments
Open

Cozy Desktop eating all standby memory on Windows #1216

aleroyer opened this issue Oct 19, 2018 · 4 comments
Labels

Comments

@aleroyer
Copy link

Description

When the desktop client is launched on Windows and you have a lot of big files, the client will access those files which cause Windows putting them in the standby memory (similar to file cache on Linux).

This is eating all my memory and affecting games performances or programs relaying a lot on memory.

I was first expected the bug from Windows itself with SuperFetch or Search features but it appears it is not. I have deactivated such features and I can see the standby memory growing after launching Cozy Desktop.

The memory can be free thanks to RamMap but it will grow again if Cozy Desktop is restarted or access huge files.

For the moment closing Cozy Desktop and clearing the standby memory is the only fix I have to enjoy games without performances issues.

Steps to Reproduce

  1. Have some big files or a lot of files in your Cozy Drive like videos from your phone
  2. Open the Resources Monitor on the memory tab.
  3. Launch Cozy Desktop
  4. See the standby memory in the resource monitor growing as Cozy Desktop scans for its files.
  5. Open RamMap and go to File Summary tab. You can sort by size on standby memory and you will see files from your Cozy folder.

Expected behaviour

Do not consume a lot of memory by opening files. Close file descriptors properly.

Actual behaviour

It seems like Cozy Desktop scans for files when starting. This is opening a lot of files in standby memory on Windows. Maybe file descriptors are not properly closed or the method used to scan files is not adapted for Windows.

Informations

  • reproductible: Always
  • OS: Windows
  • version: 3.9.0
@nono
Copy link
Member

nono commented Oct 25, 2018

Hello @aleroyer,

thanks for the detailed report. I'm currently looking to improve the desktop client on windows. It will take some times as we need to change some deep dependencies.

@aleroyer
Copy link
Author

Great! Thanks for the answer :)
I'm looking forward to it.

@nono nono added the bug label Dec 20, 2018
@nono
Copy link
Member

nono commented May 14, 2019

Hello @aleroyer,

did you try the latest release of cozy-desktop (v3.13)? We have refactored a lot of code and change the low-level library that we use for detecting changes on the file system. It should help to reduce the memory consumption.

@aleroyer
Copy link
Author

Hello @nono,

I'm currently running with the 3.13.0 on Windows. The memory consumption of Cozy Drive itself is not very high.

The problem about the standby memory is still present if you have a lot of files in Cozy (especially huge files). From what I can tell, Cozy Drive seems to open every files at startup, thus causing Windows to map each file in memory (if Windows has enough memory).

I don't think this is an issue with Cozy Drive directly but more on how Windows handle its memory (which seems pretty bad actually). Maybe there is a way to told Windows to unmap those files from memory after reading them? Or if Cozy Drive can avoid reading/opening all files at startup (so having a different method of sync I guess) it can help.

For now, I've took the habit to run RamMap and clear all standby memory before launching a game or an app that might need a lot of RAM.

After clearing this standby memory Cozy Drive doesn't fill it anymore (this happen only when the client is reading/opening files after all).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants