I think this is a bug in the WebUI.

 

The Dashboard shows one CPU code at 100% all the time. No change. It's been like this for days.

 

 

I checked htop and that core is not at 100%. It changes, but is generally low:

 

 

I checked my CPU allocations under VMs (/Dashboard/CPUset) and there are only three used VMs and that CPU (8 & 20) is pinned to a Win 10 VM. I paused that VM but it is still stuck at 100% in the WebUI.

 

 

I checked Docker and there are no CPUs pinned to anything.

 

Am I missing something or is this a bug? Is there any way to reset things (webUI or something) without having to restart the server?

 

 

 

27 minutes ago, frakman1 said:

I checked htop and that core is not at 100%. It changes, but is generally low:

Yes, but load average is very high, likely i/o wait and that's what you're seeing in the dash, diags might give more clues.

I can't see anything in the syslog ot explainthe high load. I checked again today and it's up to the 90s!

I tried running nethog and it doesn't show a big Network bandwidth usage

 

 

I tried to restart the webui portion with these commands but now the webUI won't load even though all the docker webapps still do

 

/etc/rc.d/rc.nginx restart
/etc/rc.d/rc.nginx reload
/etc/rc.d/rc.php-fpm restart
/etc/rc.d/rc.php-fpm reload

 

I don't see any errors in the syslog other than the timeouts. Is there some other log file to watch?

 

Feb 27 15:57:30 Tower nginx: 2021/02/27 15:57:30 [error] 31631#31631: *271274 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 192.168.86.22, server: , request: "POST /plugins/unassigned.devices/UnassignedDevices.php HTTP/1.1", subrequest: "/auth_request.php", upstream: "fastcgi://unix:/var/run/php5-fpm.sock", host: "tower", referrer: "http://tower/Main"
Feb 27 15:57:30 Tower nginx: 2021/02/27 15:57:30 [error] 31631#31631: *271274 auth request unexpected status: 504 while sending to client, client: 192.168.86.22, server: , request: "POST /plugins/unassigned.devices/UnassignedDevices.php HTTP/1.1", host: "tower", referrer: "http://tower/Main"
Feb 27 16:07:30 Tower nginx: 2021/02/27 16:07:30 [error] 31631#31631: *272608 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 192.168.86.22, server: , request: "GET /Plugins HTTP/1.1", subrequest: "/auth_request.php", upstream: "fastcgi://unix:/var/run/php5-fpm.sock", host: "tower", referrer: "http://tower/Main"
Feb 27 16:07:30 Tower nginx: 2021/02/27 16:07:30 [error] 31631#31631: *272608 auth request unexpected status: 504 while sending to client, client: 192.168.86.22, server: , request: "GET /Plugins HTTP/1.1", host: "tower", referrer: "http://tower/Main"

 

Running netstat reveals that it is listening on all other ports, but not on 80. 

I can ssh into the sever but don't know what else to look at

 

I've attached diagnostics. Please help!

 

tower-diagnostics-20210227-1553.zip

Edited February 27, 20215 yr by frakman1

I stopped all my VMs and docker containers but it's still inthe same state.

I looked at htop again and it's full of calls to hdparm that are in the D (uninterruptble sleep) state.

Try rebooting. 

I finally have my new hardware running and am setting up my backup server.  I have one of my threads pegged at 100% usage at all times.  I am trying to figure out why this is.  I have never seen this with my primary server.

29 minutes ago, kimifelipe said:

I have one of my threads pegged at 100% usage at all times

Check in top/htop from the CLI and see what process(es) is pegging the CPU.  Is it always the same CPU/thread at 100% or does it move around to a different one?

It is moving around.  It disappeared when i started an experimental VM and when that is stopped, it maxes out a thread again.  I am not running or doing anything on the server atm, just setting things up.

52 minutes ago, kimifelipe said:

It is moving around.  It disappeared when i started an experimental VM and when that is stopped, it maxes out a thread again.  I am not running or doing anything on the server atm, just setting things up.

Go to the terminal and type 'top' and see if wsdd is the offending process.  If it is wsdd, go into Settings -->> SMB and either disable WSD if you don't need to use it, or, enter the parameter shown below in WSD Options:

 

Thanks,

 

the top process is Xorg, at 100% cpu

 

I didnt realize i could do that, thanks

OK stupid me - i had booted Unraid in GUI mode.  I just rebooted in normal (headless) mode and its fine.