-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
[Bug]: DAV queries extremely slow with a specific user account #33453
Comments
Note: I struggled with the Github issue interface to send logs, so I only managed to send a couple of the last lines. I have already looked into them though, and nothing relevant appears before/during/after the slow queries (as related above). |
Problem still present with 24.0.4 |
Hello, i have a similar situation. |
I have the same issue on my install (Nextcloud 24.0.x on Synology NAS). And I did all the steps listed in the initial post with the same result. |
The slowness of DAV interface is pretty strange. I have NC 24.0.4 on Synology NAS with only 1 user, 3 Windows PC clients (running Owncloud client) and 1 Android Phone (with direct DAV connection via Mixplorer). Everything works smoothly and suddenly from today, none of those devices can get connect to my NC server. All clients (Windows and Android) shows "connection timeout". My NC use postgresql as database and Redis as cache. Other configurations are similiar to the OP. |
Just found out that if you delete all authtoken in database, then login slow issue is resolved immediatly! go to your database command line interface, then issue delete from oc_authtoken where login_name = 'USER_NAME'; then all the slow login issue will get resolved. You need to run this time-to-time since it will increase by time. It seems if you use several device to login, then you will get a lot of those authtoken and they are all invalided, but process then will slow down the whole login process. They are safe to remove since all desktop client will just regenerate this based on your login crendential. I believe it's a bug in NC's authtoken management system by not removing aged token from database. Someone may need to look into this.... |
Problem of brute force deletion of records from oc_authtoken is that all the clients which use manually generated auth tokens (NC Desktop Client or Android NC Client and Android DavX5 when authenticated through the NC App) cause so much failed login attempts that it took 30 Minutes in my home network subnet to be completely locked out from NC at all. Before You delete user records from oc_authtoken switch off or disconnect all client apps from the network. Then start one by one to re-authenticate your apps and clients (DavX5 Sync-Clients on Android require complete storage reset plus deletion of the nextcloud account from the app it synced before) Connect to your nextcloud database and keep an eye on oc_bruteforce_attempts. Delete every few minutes all rows containing the affected users (to be found in column metadata), ip, or subnet (don't forget ipv6 entries if your client subnets make use of ipv6) Expect 30 minutes of effort per device. Maybe the following delete statement is a bit safer: delete from oc_authtoken where login_name = 'USER_NAME' and (type = 0 or type = 2); As of my guess type = 0 are auth tokens derived by password authentication (e.g. web browser sessions) and type = 2 are deleted apps whereas for type = 1 the auth token was manually initiated for apps which are able to read QR-Codes. |
It was backported to v24: and got released with 24.0.5, still not sure if it fixes the problem.... |
@Gomez Well spotted! To try the backport, I've upgraded to 24.0.5, then manually executed Then I've tried again a DAV query as in my OP:
Success! With this cleanup in the table, I went from 41.67 secs to now 5.70 seconds… still a little slow to my taste, but hugely better! Now all my DAV-based tools (calendars mostly) are working normally again, that's a huge relief. Thank you very much @lssong99, @strenker and @Gomez for your findings and suggestions! With the fix now in the mainline code, I consider this close now. |
I can confirm that the delay is related to AD-communications. While the UI is irresponsive, the server is transfering data from Active Directory. I've tried to force cache, but it looks as if it created it in a per-user basis, as if I switch account from admin, who basically shares stuff with everyone to a key user, another batch of connections are launched against AD and it takes ages to get that PROPFIND finished again. I've increased the caching time of responses from AD in Nextcloud but it has little or no effect. How is it possible that catching these properties takes so long when NC creates a "replica" of the user-list in its own database tables? Any tips in how to speed up this? |
Bug description
Using NC server 24.0.3.
A few weeks ago, I've started realizing that trying to access anything using DAV (files, contacts, calendar, etc.) on my main user account of my own Nextcloud instance was extremely slow : between 30 and 60 seconds per DAV query (to be compared with 1 second per DAV query for other user accounts). This happens regardless of the tool/app used to make the query (curl, Firefox, Joplin webdav sync, Evolution caldav sync, etc.).
Since the problem only occurs with a single user account, I have tried understanding what is different/wrong with this account, with no success. In particular:
Therefore I believe there must be something wrong deep in my main user account, which disturbs and slows down the DAV server significantly. But I have yet to find the cause.
What I haven't tried (because I am not capable to): trying to find strange things about my old user account directly in the database.
Note that I have previously documented my problems in this thread: https://help.nextcloud.com/t/webdav-access-extremely-slow-while-regular-http-access-very-fast/142444
Steps to reproduce
These steps only apply on my Nextcloud instance.
Here an example of result in my case:
Expected behavior
I would expect the same speed as when I run a DAV query on a copy of the "slow user" (see the bug description for the context), for instance:
Installation method
Docker (official image)
Operating system
Debian
PHP engine version
8.0
Web server
Apache (behind Traefik)
Database engine version
MariaDB 10.8
Is this bug present after an update or on a fresh install?
Cannot try with fresh install (need existing user).
I will see how it goes after updating to 25.
Are you using the Nextcloud Server Encryption module?
No
What user-backends are you using?
Default user-backend (database)
Configuration report
List of activated Apps
Nextcloud Signing status
Nextcloud Logs
Additional info
Accessing files from the browser, without a DAV query, is always very fast, even with the "slow user".
The text was updated successfully, but these errors were encountered: