Bug#926310: nextcloud-desktop: High CPU Usage for several minutes when sync
(too old to reply)
Raphael Plasson
2019-04-03 09:30:01 UTC
Package: nextcloud-desktop
Version: 2.5.1-2
Severity: normal

Dear Maintainer,

I switched from the owncloud to the nextcloud client, for synchronizing my data with a private nextcloud server (v15.0.5). While the syncronization with the owncloud client goes smoothly and is almost instantaneous, it takes several minutes with one cpu used at 100%, with a freeze of the nextcloud window until completion. This happens at the first syncronization when connecting, but at each event (I tried to just add a simple and short textfile on the cloud, the nextclooud app freezes for several minutes just for adding it when it is detected on the server). Please note that I have several GB of data syncronized, if this problem can be related to my case. The syncronization, as I said before, goes smoothly with the debian owncloud client, but also with the old nextcloud client v2.3.3 from http://ppa.launchpad.net/nextcloud-devs/client/ubuntu. As such, the 2.5.1 version of nextcloud client is practically barely usable.

Thank you,

-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-4-amd64 (SMP w/24 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages nextcloud-desktop depends on:
ii libc6 2.28-8
ii libgcc1 1:8.3.0-4
ii libnextcloudsync0 2.5.1-2
ii libqt5concurrent5 5.11.3+dfsg1-1
ii libqt5core5a 5.11.3+dfsg1-1
ii libqt5dbus5 5.11.3+dfsg1-1
ii libqt5gui5 5.11.3+dfsg1-1
ii libqt5keychain1 0.9.1-2
ii libqt5network5 5.11.3+dfsg1-1
ii libqt5positioning5 5.11.3+dfsg-2
ii libqt5printsupport5 5.11.3+dfsg1-1
ii libqt5qml5 5.11.3-4
ii libqt5quick5 5.11.3-4
ii libqt5sql5-sqlite 5.11.3+dfsg1-1
ii libqt5webchannel5 5.11.3-2
ii libqt5webenginecore5 5.11.3+dfsg-2+b1
ii libqt5webenginewidgets5 5.11.3+dfsg-2+b1
ii libqt5webkit5 5.212.0~alpha2-21
ii libqt5widgets5 5.11.3+dfsg1-1
ii libqt5xml5 5.11.3+dfsg1-1
ii libsqlite3-0 3.27.2-2
ii libssl1.1 1.1.1b-1
ii libstdc++6 8.3.0-4
ii nextcloud-desktop-common 2.5.1-2
ii nextcloud-desktop-l10n 2.5.1-2
ii zlib1g 1:1.2.11.dfsg-1

Versions of packages nextcloud-desktop recommends:
pn nextcloud-desktop-doc <none>

nextcloud-desktop suggests no packages.

-- no debconf i
Raphaël Plasson
2019-04-03 10:10:01 UTC
For more information: I tried with the command line (time nextcloudcmd
--non-interactive -u user -p password -s nextcloud-directory
https://nextcloud-server), the sync takes only a couple of seconds...

The problems seems to come from the GUI, rather than from the sync
framework itself!

Raphaël Plasson
2019-10-11 05:10:02 UTC
The package is still unusable on my desktop. Am I the only one concerned
by the bug?

What happens is that the synchronisation seems to wrok correctly, it
scans the files, start to perform the update, but then the app freezes
with 100% CPU on one core for several minutes (can be tens of minutes
actually). It sometimes unfreezes for few minutes, but then the freeze
occur again, endlessly (probably each time it starts again).

This happens with kde. Launched from the terminal, the freeze is linked
to a huge load of "(process:7566): GLib-GIO-CRITICAL **: 07:06:51.918:
g_menu_insert_item: assertion 'G_IS_MENU (menu)' failed" errors.

Raphaël Plasson
2020-01-14 10:00:03 UTC
I upgraded to the last 2.6.2 version of the client and, up to now, it
seems again functional. It stills implies higher CPU usage than with the
older clients, but I do not observe again the minutes-long freezes as
observed in 2.6.0 and 2.6.1 versions (only CPU spikes for a couple of
seconds when synchronizing files).

Raphaël Plasson
2020-01-14 11:10:03 UTC
I actually experienced again (once) the freeze after som use, linked to
the same load of GLib-GIO-CRITICAL errors after some time. No specific
activities were linked to this event (only one .ods file was being
worked on during the event).

So same problem as before, but seems now more random rather than
systematic as before.