Hi, i just started having issues where the web UI is very slow to respond. Accessing pages like the docker tab, community applications tab are the worst. Looking at the network tab of community applications, the exec.php network call can take 3-30 seconds to return. If i try to access any of these heavier tabs in the UI, then typically accessing even the settings page or dashboard page will take forever to respond as well.

 

I do have a parity check running, but it is almost unusable and it wasn't like that before. I have a small set of plugins installed and have updated them. I've looked into logs, any issues i need to fix, and just don't see anything reported in the UI that would tell me there is a problem.

 

I have a ssd_cache drive that all the docker appdata is stored on with the docker img (nothing else) and the docker containers seem to be slow as well. I did do a btrfs scan and it returned no errors. See the attached zip

 

 

Tower Diagnostics Nov 21 2024.zip

Nothing that I can see in the logs, try rebooting in safe mode to rule out any plugin issues.

1 minute ago, JorgeB said:

Nothing that I can see in the logs, try rebooting in safe mode to rule out any plugin issues.

 

Will do... I did just pause the parity check and that didn't seem to help. I see in the logs that docker containers are still starting nearly an hour after i last reboot it while trying to figure out what was going on. 

 

If this is heavily related to docker, is the only option to recreate the docker image? I see that suggested quite a bit. It just feels odd that it would make the entire server crawl so bad when accessing the management ui pages. The server has plenty of resources.

55 minutes ago, rothnic said:

is the only option to recreate the docker image?

It's worth a try, since it's a fairly easy operation.

Safe mode didn't make much of a difference. The docker tab still takes forever to load, though the docker containers are running and seem to work. I guess my next option is to rebuild the docker img. It feels odd to me that it would still work and be the source of the issue though. I assumed if corrupted it just wouldn't work anymore.

System and appdata shares exist on a pool and disk6, if some files are being read/written to disk6, it can cause a slowdown.

Oh interesting... i somehow missed that one. I saw it reported some files being on another disk and moved those, but didn't see them on disk6. Trying to address that.

16 hours ago, JorgeB said:

System and appdata shares exist on a pool and disk6, if some files are being read/written to disk6, it can cause a slowdown.

 

It is incredible how much of an impact that this somehow getting moved to disk6 had on the entire unraid application. Everything was slow. I moved things back to ssd_cache and that fixed the issue. I did also then go ahead and switch to the directory mode that i didn't know existed (rather than the vdisk option) and that seems to be working great.

4 hours ago, rothnic said:

I did also then go ahead and switch to the directory mode

That usually work fine, but keep in mind that sometimes it causes strange issues, so remember that for the future.