NextCloud web interface painfully slow

[travisdh1]

@bnrstnr Something is not right in CPU land there. Can you see what process(es) are eating your CPU time?

[bnrstnr]

[bnrstnr]

@travisdh1 said in NextCloud web interface painfully slow:

@bnrstnr Something is not right in CPU land there. Can you see what process(es) are eating your CPU time?

Is there something better than top/htop to visualize the processes?

[travisdh1]

@bnrstnr Ah, yeah, every monitoring tool will peg the CPU when you first start it. Give it like 5-10 seconds and it should calm down ang give you a better look at what is actually going on.

From the looks of that screenshot, it's probably someone syncing files from within Nextcloud.

[bnrstnr]

@travisdh1 said in NextCloud web interface painfully slow:

From the looks of that screenshot, it's probably someone syncing files from within Nextcloud.

We literally have 2 users that use this right now, I have to imagine this Vultr instance should be able to handle way more than 2 users syncing. I'm the only one that uses the sync client, the other user only uses the web interface and he's not using it right now lol

[wirestyle22]

So did anything change in regards to htop

[bnrstnr]

@wirestyle22 No, it's been running for 25 minutes and still showing high CPU usage.

[wirestyle22]

@bnrstnr install glances and run that instead of htop. just curious about the reporting

[bnrstnr]

@wirestyle22

[JaredBusch]

Reboot.

[black3dynamite]

For the 504 Gateway Time-Out, and if you are using nginx has proxy, do you have this inside the location block in your nextcloud.conf file?

proxy_connect_timeout 600;
proxy_send_timeout 600;
proxy_read_timeout 600;
send_timeout 600;

[dafyre]

@JaredBusch said in NextCloud web interface painfully slow:

Reboot.

This. After you reboot, pay attention to the STEAL time. I've never noticed that in the display before... In your glances pic above, steal % is at 48%.

I had to go google it to see what it was, lol... The short version is that steal % is how long your VM has to wait until the Hypervisor gives it more CPU time.

This article, though dated, seems to give good info.
(Understanding CPU Steal Time)

[bnrstnr]

This is after reboot. It's still crazy slow. I rebooted a couple times yesterday, too. Even installing glances with DNF was crazy slow, and opening it takes about 20 seconds.

Glances had already been running for 28 min at this point, so I'm sure any spikes from opening had subsided by then.

[bnrstnr]

@dafyre said in NextCloud web interface painfully slow:

This. After you reboot, pay attention to the STEAL time. I've never noticed that in the display before... In your glances pic above, steal % is at 48%.
I had to go google it to see what it was, lol... The short version is that steal % is how long your VM has to wait until the Hypervisor gives it more CPU time.
This article, though dated, seems to give good info.
(Understanding CPU Steal Time)

This almost sounds like I have a noisy neighbor on my VPS?

[bnrstnr]

@black3dynamite said in NextCloud web interface painfully slow:

For the 504 Gateway Time-Out, and if you are using nginx has proxy, do you have this inside the location block in your nextcloud.conf file?

proxy_connect_timeout 600;
proxy_send_timeout 600;
proxy_read_timeout 600;
send_timeout 600;

I have nothing relating to timeouts in my nginx conf.

Should I add it? I'm assuming it's using whatever the nginx default is.

[travisdh1]

@bnrstnr said in NextCloud web interface painfully slow:

@dafyre said in NextCloud web interface painfully slow:

This. After you reboot, pay attention to the STEAL time. I've never noticed that in the display before... In your glances pic above, steal % is at 48%.
I had to go google it to see what it was, lol... The short version is that steal % is how long your VM has to wait until the Hypervisor gives it more CPU time.
This article, though dated, seems to give good info.
(Understanding CPU Steal Time)

This almost sounds like I have a noisy neighbor on my VPS?

Very well could be.

[JaredBusch]

@bnrstnr said in NextCloud web interface painfully slow:

@dafyre said in NextCloud web interface painfully slow:

This. After you reboot, pay attention to the STEAL time. I've never noticed that in the display before... In your glances pic above, steal % is at 48%.
I had to go google it to see what it was, lol... The short version is that steal % is how long your VM has to wait until the Hypervisor gives it more CPU time.
This article, though dated, seems to give good info.
(Understanding CPU Steal Time)

This almost sounds like I have a noisy neighbor on my VPS?

I would definitely submit a ticket to Vultr about it.

[scottalanmiller]

@bnrstnr said in NextCloud web interface painfully slow:

EDIT: This instance is actually Fedora 27, not 28.

Not your issue, but troubleshooting two versions behind is never ideal. Get up to Fedora 29 before investigating further.

But NC requires a lot of resources and is always decently slow on the web page. But not ten seconds slow.

Our NC is Fedora 29, heavily tuned, has like six cores, 12GB of RAM, doesn't have any noisy neighbours (not cloud) and you still feel the lag if doing the web interface.

[black3dynamite]

@bnrstnr said in NextCloud web interface painfully slow:

@black3dynamite said in NextCloud web interface painfully slow:

For the 504 Gateway Time-Out, and if you are using nginx has proxy, do you have this inside the location block in your nextcloud.conf file?

proxy_connect_timeout 600;
proxy_send_timeout 600;
proxy_read_timeout 600;
send_timeout 600;

I have nothing relating to timeouts in my nginx conf.

Should I add it? I'm assuming it's using whatever the nginx default is.

For Nextcloud, yes. It also helps with when updating Nextcloud via the web interface too.

[scottalanmiller]

@bnrstnr said in NextCloud web interface painfully slow:

We have WOW cable internet, like 240/20ish

I've poked around and found some other users NC installs and their login pages load almost instantly for me

Vultr storage instances are very slow, they are meant for capacity, not speed. This will definitely contribute to the issue.

Make sure you have swap available. 2GB isn't terrible, but not quite enough for even a tiny instance to run unimpeded.