[6.12.4/5/6] Major GUI delays after upgrade (specially dashboard, docker and apps tab)

Tested the latest release 6.12.6.

Still the same.  Any devs looking at this issue? I'm not the only one here with the same issue I see.

 

Edited March 28 by CiscoCoreX

17 hours ago, CiscoCoreX said:

I'm not the only one here with the same issue I see.

 

Just wanted to weigh in I'm experiencing this _exact_ issue.  Thanks for all the work to test and report back; you're definitely not alone in experiencing this.

It is unclear why this is happening, could be specific to your set up.

 

Try the following

 

1. Make a backup of your current flash device, see Main -> Flash -> Flash Backup

2. Install the plugin “Dynamix Factory Reset”

3. Do a factory reset and keep your disk assignments.

4. After a reboot the system has all default settings

 

Check the behavior of the GUI in this state

 

You can restore docker containers by installing CA and use it to do a restoration (make sure your docker settings are correct before doing so)

 

Configure your VM settings as required and re-install VMs by creating a new VM and select the existing image.

 

If desired you can always restore the flash device from the backup using the creator tool.

 

 

This is not about hiding a bug, but starting from scratch and add things back to determine when and where it goes wrong.

 

15 hours ago, bonienl said:

This is not about hiding a bug, but starting from scratch and add things back to determine when and where it goes wrong.

 

Hi, give me a day or two. Then I'm going to do an clean install + just add my license key.
I did this on an early post here, I think it was on version 6.12.4. Then same problem.

I'm also experiencing the same problem with 6.12.6 after recently upgrading from 6.11.5.  Currently rolled back to 6.11.5 waiting for a resolution to this.

On 12/6/2023 at 5:47 AM, bonienl said:

It is unclear why this is happening, could be specific to your set up.

 

Try the following

 

1. Make a backup of your current flash device, see Main -> Flash -> Flash Backup

2. Install the plugin “Dynamix Factory Reset”

3. Do a factory reset and keep your disk assignments.

4. After a reboot the system has all default settings

 

Check the behavior of the GUI in this state

 

You can restore docker containers by installing CA and use it to do a restoration (make sure your docker settings are correct before doing so)

 

Configure your VM settings as required and re-install VMs by creating a new VM and select the existing image.

 

If desired you can always restore the flash device from the backup using the creator tool.

 

 

Hi,

- I just did an clean install of the latest version 6.12.6. Just downloaded the zip file and extracted to my USB pen and copy my license key.
- Booted up my backup server

- Made a new root password.

- Signed in for the first time

- First time it goes ti the MAIN page. I didn't assiged any disk this time. No Arrray or Cache.
Now the speed is much more normal, around 1 - 2 seconds when I go back to Dashboard page from any other page.

 

- Next thing I did was changing the timezone, after that the problem start again. Slow Dashboard, almost 20 seconds.

I change back do default settings in the "Time and Date" but still same, slow Dashboard. Rebooted the server.

- But that didn't help. So the problem is back. Slow, Did another reboot.

- Same again after a reboot.

- I turn off use NTP and rebooted again. Same problem. I don't believe NTP has something to do with this slow pages.

 

So what has changed since 6.12.3 to 6.12.4 when my problem start?
My primary server are stuck on version 6.12.3

 

 

Edited March 28 by CiscoCoreX

Please test the following to see what is being executed while the delay happens:

 

1. Open /etc/php-fpm.d/www.conf
2. Uncomment ";slowlog ="
3. Adapt the same line to "slowlog = /var/log/php.slow.log"
4. Uncomment ";request_slowlog_timeout = 0"
5. Change the same line to "request_slowlog_timeout = 10"

 

Open a terminal (SSH) and type in "/etc/rc.d/rc.php-fpm restart"

 

Try to reproduce the delay. After this, Upload the file at /var/log/php.slow.log here. Then please add a semicolon (;) to BOTH changed lines again and restart PHP-FPM again.

 

This will show us a trace on the portion of code, which lasts longer than 10 seconds.

 

Offtopic: The Pool Config could get updated to latest package templates - inside of the current one there still PHP5 metioned. The nginx socket paths could get updated too..

Edited December 9, 2023 by KluthR

On 12/9/2023 at 5:17 PM, KluthR said:

Please test the following to see what is being executed while the delay happens:

 

1. Open /etc/php-fpm.d/www.conf
2. Uncomment ";slowlog ="
3. Adapt the same line to "slowlog = /var/log/php.slow.log"
4. Uncomment ";request_slowlog_timeout = 0"
5. Change the same line to "request_slowlog_timeout = 10"

 

Open a terminal (SSH) and type in "/etc/rc.d/rc.php-fpm restart"

 

Try to reproduce the delay. After this, Upload the file at /var/log/php.slow.log here. Then please add a semicolon (;) to BOTH changed lines again and restart PHP-FPM again.

 

This will show us a trace on the portion of code, which lasts longer than 10 seconds.

 

Offtopic: The Pool Config could get updated to latest package templates - inside of the current one there still PHP5 metioned. The nginx socket paths could get updated too..

Hi,

 

Here is the new log file included and diagnostics if needed.

 

Thanks for looking at this issue.

php.slow.zip

Edited March 28 by CiscoCoreX

Followed the same steps (using Unraid version 6.12.6 on Chrome browser)

 

1. Start system with factory settings

2. Change default timezone to my own timezone (Europe)

 

Loading the Dashboard page is always instant.

 

A couple of things you can try, which hopefully give more insight

Try each suggestion at the time to see its effect.

 

1. Access the system using its IP address. e.g. http://192.168.1.100 (replace by your server address)

2. Under network settings change to a static DNS server assigment, e.g. use 1.1.1.1 or 8.8.8.8

3. Under display settings change "Show Dashboard apps --> None"

4. Do a file system check (using Windows) on your USB device to check for any errors to repair

 

Ps. The file "php.slow.log" shows the dashboard page loading takes a long time (duh) without further details.

 

Just want to chime in and say that I’ve been having the exact same issues since upgrading to 6.12.4. Thanks for bringing this topic up

17 hours ago, bonienl said:

Followed the same steps (using Unraid version 6.12.6 on Chrome browser)

 

1. Start system with factory settings

2. Change default timezone to my own timezone (Europe)

 

Loading the Dashboard page is always instant.

 

A couple of things you can try, which hopefully give more insight

Try each suggestion at the time to see its effect.

 

1. Access the system using its IP address. e.g. http://192.168.1.100 (replace by your server address)

2. Under network settings change to a static DNS server assigment, e.g. use 1.1.1.1 or 8.8.8.8

3. Under display settings change "Show Dashboard apps --> None"

4. Do a file system check (using Windows) on your USB device to check for any errors to repair

 

Ps. The file "php.slow.log" shows the dashboard page loading takes a long time (duh) without further details.

 

Hi,

1. 

1. Access the system using its IP address. e.g. http://192.168.1.100 (replace by your server address)

I always use ip to login into my unraid: http://10.10.60.105/

 

2. Under network settings change to a static DNS server assigment, e.g. use 1.1.1.1 or 8.8.8.8

 

3. Under display settings change "Show Dashboard apps --> None"

Nothing change, still the same.

 

4. Do a file system check (using Windows) on your USB device to check for any errors to repair
Did a check on my USB driver, no error found. This is also 2nd time I did an clean install, formatted the USB drive also.

 

Edited December 10, 2023 by CiscoCoreX

17 hours ago, bonienl said:

Ps. The file "php.slow.log" shows the dashboard page loading takes a long time (duh) without further details.

And why dont we dig deeper there? There are further details.

 

I checked the eval'd code. The affected page is DashStats and line 53 is the docker status exec.

I asked him to execute the rc.docker status command and this command takes ~20 secs to complete, so here we have our issue at least for him.

 

The question is: Is this the same cause for all others? And if yes, what is taking so long time inside the rc.d script for some users.

 

For others having the issue, I would ask them to execute the command "/etc/rc.d/rc.docker status" in a terminal and observe, how many seconds it need to generate output.

 

That are my findings. Correct me if anything looks wrong.

2 hours ago, KluthR said:

The question is: Is this the same cause for all others? And if yes, what is taking so long time inside the rc.d script for some users.

 

 

Not the cause for me.  After upgrading to 6.12.6 and noticing this slow GUI response on dashboard, I disabled VMs and Docker services, rebooted.  Problem was still there.  I even rebooted without starting the array, same problem.  🤷‍♂️

But is the mentioned command taking so long anyway? Unraid calls this command regardless of docker/vms enabled/disabled. If there is any "issue" in the script, it could be triggered anyway. Please try it and report back.

 

EDIT: If the docker status command is not delaying, please share the PHP-Slowlog for your system.

Edited December 10, 2023 by KluthR

Yes, seems unnecessary, but why is a sed so slow?

I just checked - the rc.docker command has this sed in it as well. Those write back to USB Boot drive. This is what me brings me back to bonie's suggestion to check the Boot-Drive. The sed would be extremely slow, when writes to the USB drive would be slow (a failing device maybe?). But ANY write would be slow then.

 

Maybe a performance check with CrystalDiskMark would expose issues writing to the USB key.

 

Iam very curious if this could be the root cause for all affected users.

I let @CiscoCoreX do several „echo 1 > /boot/test.xml“ which delayed up to 6 seconds. (Btw, could you test „echo 1 > /mnt/user/someshare/test.txt“ with started array and real share name?)

 

downgrading fixes all delays.

 

The issue seems to be Linux related. At least nothing to do with webgui.

 

anyway, Iam out now. The slowlog brought a new finding which was my only idea 😂

 

Maybe LimeTech can share some thoughts on this.

18 hours ago, KluthR said:

I let @CiscoCoreX do several „echo 1 > /boot/test.xml“ which delayed up to 6 seconds. (Btw, could you test „echo 1 > /mnt/user/someshare/test.txt“ with started array and real share name?)

 

I did run your command: echo 1 > /mnt/user/appdata/test.txt

It responded imminently, no delay

 

The command: echo 1 > /boot/test.xml
Gave me a delay around 5 - 6 seconds.

 

But the best part, I did run this command ( echo 1 > /boot/test.xml ) on my primary unraid server, still on version 6.12.3.
And have the same delay as on my backup server with version 6.12.6.
Interesting since my version 6.12.3 are working perfectly fine on booth computers. 

I uploaded to short recording of the delay on booth servers.

Pegasus 6.12.3.zip Backup_Server_6.12.6.zip

Edited December 12, 2023 by CiscoCoreX

I made an update for two files which check for changes in the docker configuration and update as needed.

The check now also looks for the presence of _SUBNET_ to make valid changes.

 

rc.docker --> copy this file to folder /usr/local/etc/rc.d and make the file executable (chmod +x rc.docker)

DockerClient.php --> copy this file to folder /usr/local/emhttp/plugins/dynamix.docker.manager/include

 

Please test if this solves the delays.

Thx.

 

dashboard-test.zip

@bonienl
I just copied your files, and now the dashboard is fast

But the APPS page are just white.

 

And DOCKER page is missing something. Same if you go to Settings ---> DOCKER, nothing happening, just white page.

 

And the DOCKER page:
 

But the Dashboard is fast 

Edited December 12, 2023 by CiscoCoreX

7 hours ago, bonienl said:

I made an update for two files which check for changes in the docker configuration and update as needed.

Did not took a look but what is the fix actually? Calling exec with sed only of really needed?

 

If yes: This fixes the always-calling-sed-issue but what is the underlying write-to-boot-is-slow issue then?

@CiscoCoreX

Can you go to Tools -> PHP Settings

 

Error reporting level = All Categories

 

Then open the View Log

 

Revisit the pages which end up blank and observe the PHP log for any errors.

Please post these errors.

Thx

Fixed my typos, please use the updated files.

 

@KluthR

The fix is not really the answer to the root cause, which I don't know but it prevents unnecessary writing to the flash device.

 

 

@CiscoCoreX

I made some typos, sorry for that.

 

Here are the updated files

 

dashboard-test.zip

5 hours ago, bonienl said:

@CiscoCoreX

I made some typos, sorry for that.

 

Here are the updated files

 

dashboard-test.zip

Hi @bonienl

Good news, It's working. All the pages are fast like normal.  
Would be nice to see other with similar problem, test your files also.

Desktop 13-12-2023 17-56-03.zip

Edited December 13, 2023 by CiscoCoreX