Occasionally very slow root directory PROPFIND

ℹ️ Support
1

Nextcloud version (eg, 20.0.5): 23.0.0
Operating system and version (eg, Ubuntu 20.04): debian something
Apache or nginx version (eg, Apache 2.4.25): nginx something
PHP version (eg, 7.4): 8.something

Sometimes the PROPFIND https://mydomain/remote.php/dav/files/myuser/ will take a very long time (20s+) instead of ~100ms normally. This results in the web interface (/apps/files) loading slowly and also affects the desktop clients, usually it will work fine but sometimes it gets stuck until the proxy aborts the connection (timeout set to 5 minutes).

I found this issue but it doesn’t apply, I only have 8 devices.

Is this a common problem? Does someone have any hints as to what might cause it or how to troubleshoot?

Installed apps 
  - accessibility: 1.9.0
  - admin_audit: 1.13.0
  - breezedark: 23.1.0
  - calendar: 3.0.4
  - cloud_federation_api: 1.6.0
  - contacts: 4.0.7
  - dav: 1.21.0
  - extract: 1.3.3
  - federatedfilesharing: 1.13.0
  - files: 1.18.0
  - files_external: 1.15.0
  - files_pdfviewer: 2.4.0
  - files_rightclick: 1.2.0
  - files_sharing: 1.15.0
  - files_trashbin: 1.13.0
  - files_versions: 1.16.0
  - files_videoplayer: 1.12.0
  - forms: 2.4.0
  - keeweb: 0.6.8
  - logreader: 2.8.0
  - lookup_server_connector: 1.11.0
  - notifications: 2.11.1
  - notify_push: 0.3.0
  - oauth2: 1.11.0
  - phonetrack: 0.6.9
  - photos: 1.5.0
  - provisioning_api: 1.13.0
  - settings: 1.5.0
  - sharebymail: 1.13.0
  - text: 3.4.0
  - theming: 1.14.0
  - twofactor_backupcodes: 1.12.0
  - twofactor_totp: 6.2.0
  - updatenotification: 1.13.0
  - viewer: 1.7.0
  - workflowengine: 2.5.0
2

Nextcloud version (eg, 20.0.5): 24.0.1
Operating system and version (eg, Ubuntu 20.04): Ubuntu 20.04.4 LTS
Apache or nginx version (eg, Apache 2.4.25): Apache 2.4.52
PHP version (eg, 7.4): 7.4.3

I have the same behaviour since at least two years and Nextcloud 18, (now on 24.0.1). I have 3 synced devices and 5 users (only I use a desktop client).
I suspected several things:

a) I have a rather large amount of files (166k files, 24k subdirectories, 350 GB total size), however the root directory contains only 25 subdirectories and files. Switching the entire machine to an NVMe drive did marginally speed up the browsing, but did not improve the problem.

b) I had external SMB shares, which after removing did not change anything

c) For a while, I thought it was gone after fiddling with the caching, but the delay came back (or it stayed). My current cache settings are:
‘memcache.local’ => ‘\OC\Memcache\APCu’,
‘memcache.locking’ => ‘\OC\Memcache\Redis’,
‘memcache.distributed’ => ‘\OC\Memcache\Redis’,
‘redis’ =>
array (
‘host’ => ‘/var/run/redis/redis-server.sock’,
‘port’ => 0,
‘dbindex’ => 0,
‘password’ => ‘xxxxxxxxxxxxxxxxx’,
‘timeout’ => 1.5,
),

d) When it works, PROPFIND takes about 40ms. When it doesn’t, it takes around 3 minutes(!) before returning the same result it usually gives after 40 ms.

e) While processing the PROPFIND, the server is practically idle. No CPU load, no disk load, no network load.

If anyone has an idea what I can do to debug this issue, please tell me/us. Thanks!

3

Still the same, almost a year later. I assume you haven’t found a solution in the meantime either?

4

I finally managed to solve the issue! There was a strange share entry in the oc_share_external table from some IP address in a private network range I was using years ago. After deleting it, everything is fine, finally!

1 Like
5

I had not encountered the problem for a while, however I also had some old entries in the oc_share_external table. Thank yor for the excellent detective work!
This thread will surely help people with the same problem :slight_smile:

6

wow! thank you! It helped me a lot. there are a couple of resources left that were sent to me from another federation server. this server is no longer there and these records were only in the database. they were not displayed anywhere in the web interface.

1 Like