-
-
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
files_sharing makes TTFB take ~2 minutes #7001
Comments
Currently my Nc server is down so I can't test this but as soon as I am back home (Nov 9) I'll give it a try, see if disabling the files_sharing app solves the problem. I did try to disable sharing in the admin panel but that didn't help. There must be a share (or more than one) which causes this extreme slow-down. Might be a (broken?) federated share, perhaps? |
cc @nextcloud/sharing |
Yeah, I think so to. But how do I find it? @MorrisJobke Do you know any good SQL query for PostgreSQL? |
I suggest that:
@jospoortvliet Have you had any success in finding the cause? I just removed some federated shares, but it still didn't help. :/ |
Something is defently wrong with files_sharing:
X = my input. There is no share with jvabmolnet.se as I removed it. I also did a |
How can I remove ALL federated shares from specific folders in one go? |
cc @nextcloud/sharing |
Just tested with 13.0.0beta1 and it's still the same issue. @jospoortvliet Did you manage to solve it? |
@enoch85 Any chance, that we can install the blackfire.io php extension on that machine, set it up with my account and run some profiler on it? |
@MorrisJobke Sure! How do we proceed? |
This is the blackfire profile from the session with @enoch85 https://blackfire.io/profiles/82cf5cfa-4296-4cd7-a09a-e751ad4d447f/graph There is a federated share that is unavailable: select * from oc_storages where numeric_id = 45;
id | numeric_id | available | last_checked
------------------------------------------+------------+-----------+--------------
shared::8979944323bb262c7830bd591543ec0a | 45 | 0 | 1510879755 We should not run into timeouts on the files app page load then. The remote server is just not there anymore. |
All pages are slow, not just the files app. When turning off files_sharing every page takes like 500 ms or less to load. |
I know you are busy guys, but I would love to se this solved soon. My cloud is unusable since this happened. Please? :) @MorrisJobke @schiessle @icewind1991 |
So I just tested Nextcloud 13 Beta 2, disabled the sharing app and - lo and behold - the problem is entirely gone. I had no other issues. Yes, I upgraded my private instance. Without backup. Bite me! 🐶 But after enabling the sharing app - slow again. Back to disabling the sharing app. This is worth fixing asap, I'd say. Not a regression but it makes Nextcloud unusable with federation @schiessle |
@jospoortvliet That the
I was hoping for 13.0.0, but it seems dark. :( Still, two weeks left I heard, so there is hope! Please? |
I mean if @jospoortvliet and I are affected, there must be several more, but who is not reporting and thinking Nextcloud is crap because of this bug. So, I'd say it's best for reputation to fix this. |
I hope my emojois are enough to express my gratitude! Must test! |
Wow, it works. Thanks a ton guys! |
I'm afraid I am experiencing these exact symptoms on Nextcloud 13.0.0 (and previously on 13.0.0-RC4, this instance is on the Beta channel). If I disable the file sharing app then all is good. As soon as I enable it back, there is an ~11 / 12 second gap between requests.
Disabling the Federation app did not make any difference. I am now trying to determine whether all incoming federated servers are up. This is proving challenging due to the unusably slow performance but I'll update when/if I get new info. |
@9662 do you have a memcache configured? |
Not on this instance, no. |
Well in that case we don't cache it. Enable APCu (and configure it in config.php) and it should work. |
What about using Redis instead? |
Also fine |
Working fine now. Vielen Dank! |
Steps to reproduce
Expected behaviour
TTFB should be quick even with many shared links and federated shares.
Actual behaviour
As soon as File Sharing is activated (the app) TTFB is around 2 minutes and sometimes more.
I also tried with changing to Nginx because I thought it was an Apache error, but Nginx timed out because it took such a long time. When I increased the timeout for PHP-FPM the end result was the same, around 2 minutes.
Other than that I check PostgreSQL (that was the first thing I thought was the cause) but after talking to some DB experts that helped me do some digging, we found that PostgreSQL is not the error, everything is superfast there.
I also tried to disable most of the federated shares, but it didn't help much.
Also, the "worst" user is my own, becuase I have the most shared links. It's slow for other users as well, but not even close to 2 minutes. Around 30 seconds.
cc @jospoortvliet for the same issue as me.
General server configuration
Operating system: Linux domain.techandme.se 4.4.0-97-generic #120-Ubuntu SMP Tue Sep 19 17:28:18 UTC 2017 x86_64
Web server: Apache/2.4.18 (Ubuntu) (apache2handler)
Database: pgsql PostgreSQL 9.6.5 on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609, 64-bit
PHP version: 7.0.22-0ubuntu0.16.04.1
PHP-modules loaded
Nextcloud configuration
Nextcloud version: 12.0.3 - 12.0.3.3
Updated from an older Nextcloud/ownCloud or fresh install: Updated
Where did you install Nextcloud from: Nextcloud.com
Are you using external storage, if yes which one: no
Are you using encryption: no
Are you using an external user-backend, if yes which one: no
Signing status
Enabled apps
Disabled apps
Content of config/config.php
Client configuration
Browser: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/62.0.3202.62 Chrome/62.0.3202.62 Safari/537.36
Operating system: Ubuntu Budgie 17.10
Logs
Web server error log
Nextcloud log (data/nextcloud.log)
Browser log
The text was updated successfully, but these errors were encountered: