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

High CPU load with 2.5.x clients on Fedora 30 #1285

Closed
ghost opened this issue Jun 3, 2019 · 7 comments
Closed

High CPU load with 2.5.x clients on Fedora 30 #1285

ghost opened this issue Jun 3, 2019 · 7 comments

Comments

@ghost
Copy link

ghost commented Jun 3, 2019

Nextcloud 2.5.x clients for Fedora 30 use permanent high cpu load (one core 100%).

Expected behaviour: Should not use much CPU capacity.
Actual behaviour :Permanent 100% cpu load
Steps to reproduce:

Have 2 NC servers under management
Start Nextcloud client.

Client configuration
Client version: 2.5.0, 2.5.2
Operating system: Fedora 30
OS language: French
Installation path of client:

Server configuration
Docker images from https://github.com/nextcloud/docker with nginx/fpm/MariaDB/
NC 15.0.7
Operating system: Debian 9
Web server: Nginx
Database: MariaDb 10.3.14
PHP version: php-fpm 7.3.4
Nextcloud version: 15.0.7
Storage backend (external storage): s3ql

Nextcloud-client 2.3.3 was working fine on Fedora 29, but 2.5.0 on Fedora 29 had a similar issue.

@ghost ghost changed the title Permanent Sync & high CPU load with 2.5.x on Fedora 30 High CPU load with 2.5.x clients on Fedora 30 Jun 3, 2019
@tflidd
Copy link

tflidd commented Aug 4, 2019

There are some more reports with the 2.5 branch on linux desktops:
https://help.nextcloud.com/t/high-cpu-load-linux-desktop-client/33628

@tflidd tflidd added the bug label Aug 4, 2019
@mcvayokay
Copy link

Still an issue on desktop client 2.6.2 and Fedora 31. 100% CPU usage on one core at all times, and the file sync never actually progresses.

@sweichwald
Copy link

I also encountered essentially permanent sync and high CPU load for clients 2.5.x and 2.6.x on *buntu and arch for nextcloud server 19.0.1.1 (and earlier) as reported here and in similar mac #1274 and micisoft #853 issues. #1983 may possibly be related, too.

The problem may be related to federated shares and this server issue nextcloud/server#19647. In my case, the client was performing a full sync every minute as the server reported a new ETag for the federated shares irrespective of whether there were any changes. (In fact it is more subtle, as the problem only occurs if you are receiving end of the federated share and at least once failed to delete a file from the federated share, cf. nextcloud/server#19647.)

If one is using federated shares and suffering from this cause of high client CPU load, one should see

  • regular and frequent (i.e. ~once every minute)
    • repetitions of slotRunEtagJob followed by ETag CHANGED lines when running nextcloud --logdebug --logfile -,
    • syncrun activity logged in ~/.local/share/Nextcloud/*.log,
  • the webclient showing "last modified < 1 min" for the affected federated share folders when entering those and immediately moving up to the parent directory again,
  • the CPU load dropping upon removal of the federated shares or excluding them from synchronisation in the client.

@FelixSchwarz
Copy link

Fedora 33+ currently ships nextcloud 3.0.3 and I don't see high CPU load here. Is this still an issue when using the latest version?

@zachsmith
Copy link

I am still seeing this on Fedora 33 with 3.1.1

@github-actions
Copy link

github-actions bot commented May 6, 2021

This bug report did not receive an update in the last 4 weeks. Please take a look again and update the issue with new details, otherwise the issue will be automatically closed in 2 weeks. Thank you!

@github-actions github-actions bot added the stale label May 6, 2021
@github-actions
Copy link

This bug report is getting automatically closed due to no answer since the issue has been staled. Thank you!

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

No branches or pull requests

5 participants