Nextcloud version: 220.127.116.11
Operating system and version: Ubuntu 16.04
Apache or nginx version: 2.4.18
PHP version: 5.6.23
Is this the first time you’ve seen this error?: Yes
Successfully upgraded to 12 from 11.0.3 and for all users except one everything is working just fine.
The main user who is also the admin of the site has a lot of files and also had lots of contacts (around 2000). As the web client in any browser (tested Chrome, Firefox and Opera) is very slow - i.e. each site requests needs 10-50 seconds to respond - I tried the following things without any luck:
- Deleted the address booko with the huge number of contacts
- Disabled the contacts app
- Disabled Nextant
- Browsing in onkognito mode
Nothing helps. When I login as a different user though, then everything is working just fine. But for my original user account it is not usable.
I checked the browser console, it doesan’t show any errors but the network tab shows TTFB of 10 seconds up to over a minute for certain components. Again, the same browser for a different user is just working fine.
I checked all logs and nothing indicating any problems.
Also, using the desktop client and the Android client for that problematic user is also working just fine without any delays.
I’m running out of ideas and wonder if anyone could actually help me with more aspects on what I could be trying.
In addition please have a look at the waterfall wher you can see the HUGE TTFB for some (i.e. most) of the components.
My previous statement, that the desktop and Andoird app were operating normally, was obviously wrong. What I saw came from cached data and in reality those two are as slow as the web app. It really looks like Nextcloud does something very special for that user for each request, the really long TTFB can’t be explained any differently.
Any ideas anyone?
I read that PHP7 has a better performance. Maybe an update is worth it.
Do you use theming and want to try disabling it?
What do the logs (nextcloud and maybe system logs) say?
Is there a very high load on the system?
When I updated our environment to php 7.1 from php 5.6 it was a night and day difference with performance. I also enabled caching which was a big help with the amount of files and pics we move throughout our environment.
Well, certainly an update to PHP 7.x would make a big difference but on that server I have some older PHP applications that are not yet compatibel with it.
And what’s more, there are other users on that Nextcloud instance that work just fine and there are 4 Nextcloud instances on that host and none of them shows an effect like this. That’s why I’m certain that something with the data for that user is special.
Theming: only a company logo is used and thatÄs the case for all users. All the others are fine, so why should that cause an issue for a single user?
Server logs and performance: nothing in the logs and the ressources are in good shape. So there is no indication from the environment, it really seems to come from NC application.
OK, that user has a lot of files (60GB altogether) and this is the only difference to the other users that I can recognize. Is NC doing anything with the list of files when bootstrapping a NC request?
I also have the problem with low performance since update from 11.0.3 to 12.0
system cent os 7.3 php 7.1.5
opcache, redis, fpm configured
at the moment the list below is very slow:
Filesync with clients (ios, desktop)
Collabora Online (when loading document)
OnlyOffice (when loading document)
What’s interesting here: over the copurse of the weekend it seems that things got better. My guess is that cron jobs updated things such that it is now normal speed again. Is that the case?
after the weekend the speed problem is not solved.
in my case cron.php runs every 15 minutes
the same configuration was used with nextcloud 11.0.3 with no problems
to view a picture in the gallery with 150k in fullscreen mode, it takes between 30 and 80 seconds. the apache process takes 50% of cpu at the file loading.
with nextcloud 11.0.3 it takes max. 2 seconds for the same pic.
if a calendar was shared with a group in nextcloud 11, the same action will not work with nextcloud 12. for me the version 12 is still in beta state and not a stable version.
You’re right, the problem is hitting me again as well. So the good behaviour was just a bit of luck on a Monday morning I guess.
Let’s quickly summarize the situation again:
- I have 4 instances of Nextcloud on a host in the cloud
- 3 of them without any problems
- On the 4th instance, there are 5 users without a problem but 1 user which has the most data (files, calednar, contacts) and that one experiences heavy delays in the web interface and also clients (Thunderbird, Linux desktop and Android app) are not working nicely or not at all
What can we do to analyse and fix this problem?
I just had the same issue for one of my users: the login was extremely slow (taking minutes to see the file view).
My problem was solved by deleting two remote shares to external servers which where not responding.
This seemed to slow down everything for this user.
As the shares were not responding they could not be deleted from the web interface, i had to drop their entries from the “oc_share_external” database table.
Oh wow, this is exactly it !!! Thank you so much @chris-est - you already made my day
I have no external shares!!! my problem is still active.
@Heiko those are not displayed in the UI, at least not those that cause this problem I had. Have you checked the database tables directly?
I did check the database. there are no errors and the table oc_share_external is empty
OK, then your problem seems to be a different one, unfortunately.
Since the update to 12, i have the same problem like @Heiko
no error and no entries in oc_share_external
@Heiko, try this:
Try making use of ramdisk. it help me a lot
Open the /etc/fstab and add the follwing code to enable ramdisk for /tmp and /var/tmp
Add the following rows to the end of this file:
tmpfs /tmp tmpfs defaults,noatime,nosuid,nodev,noexec,mode=1777 0 0
tmpfs /var/tmp tmpfs defaults,noatime,nosuid,nodev,noexec,mode=1777 0 0
Save and quit the file and mount the tmpfs-filesystem manually.
mpfs (ramdisk) is now used by your server even after having rebooted your server. To either move cache directories to ramdisk, create the file “/etc/profile.d/xdg_cache_home.sh”
and paste the following two rows:
Save and quit
chmod +x /etc/profile.d/xdg_cache_home.sh