Crazy-slow WebGUI

[MoebiusStreet]

I'm a new-ish unraid user, with a server that's been up for about two months now. But within the last few days, the performance of the WebGUI has suddenly become unusable, taking whole minutes to refresh the "Main" window, for example. Performance as a file server is fine, and everything "feels" fine when I connect via ssh.

 

Since I'm a newbie, I don't really know what to look at. But as I check the syslog.txt, one thing jumps out at me, whole bunches of lines like this (the name of my server is jabba because it's fat and is holding Princess Leia):

Dec 15 14:26:57 jabba emhttp: err: sendFile: sendfile /usr/local/emhttp/update.htm: Broken pipe
Dec 15 14:26:57 jabba emhttp: err: sendFile: sendfile /usr/local/emhttp/update.htm: Broken pipe
Dec 15 14:26:57 jabba emhttp: err: sendFile: sendfile /usr/local/emhttp/update.htm: Broken pipe

Hoping one of you wizards can help out this newbie.

jabba-diagnostics-20171215-1641.zip

[MoebiusStreet]

Some additional information:

• Disabling my ad blocker and my antivirus makes no difference.
• It occurs as accessed from multiple computers.
• Rebooting the server makes no difference.

Could it be getting worse? At the moment the web servers seems to have physically accepted the connection - the browser's not giving a timeout error. But absolutely no data is being returned.

[Squid]

What you're basically running into is the fact that the webUI on 6.3.5 is tied up with something else and/or crashed.

 

You're running with 3G of memory (probably 4G installed).  This won't help.  Go into the BIOS settings, and change the amount of memory allocated for the onboard video down to the lowest it will support.  (unRaid's video is text only, so 16Meg if the BIOS supports that is more than sufficient)

 

Also consider upgrading to 8G if you want to run docker containers. 

[MoebiusStreet]

As far as I can find, there's no option in my BIOS settings to limit the memory allocated to video.

 

But I did try booting the server into unraid Safe mode, with no plugins. In this mode, the WebGUI works fine. This is consistent with your theory: plugins could be using memory that WebGUI needs. However, it's also consistent with a theory that there's a broken plugin.

 

I'll order another 4GB RAM - the $40 it'll cost is worth getting rid of the headache. But for future reference, is there a way to address such a problem with the plugins? That is, if they're breaking WebGUI, is there a way I can, say, remove one plugin at a time via ssh until I get to a state where things work (hypothetically)?

[NewDisplayName]

Yeah, i also had this, if ram is full, unraid needs 5-10 min to respond. 

[MoebiusStreet]

Aaargh! No! I spoke too soon. It was working fine (in safe mode) right after booting, and I set it to doing a parity check because it said it wanted to. However, now when I go back to the WebGUI, it's hanging, or at least taking a hugely long time to provide the response, just as before.

 

So if I wait long enough for the dashboard page to finally come up, that's telling me that memory usage is only at 26%. This cuts against the memory theory. Also, once the page is up, it continues to provide updates to the system usage stats, as well as the percentage that the parity check is complete.

[MoebiusStreet]

This should be my last follow-up. I just upgraded to 6.4.0, and the new architecture for the WebGUI seems to have completely eliminated my problem.