GUI problems since patch 8.0.0.2084

[Nilsn]

Hi
We are having huge problems since we applied patch 8.0.0.2084.
The GUI is unstable and hangs reportedly, when we try to enter "Backups > Disk" the GUI freezes completely.
We have a case with the support on this issue but i would like to see if anyone else is having the same issues regarding the not functioning GUI after patch 8.0.0.2084
Veeam casenr: 01090610
The case status now is to start clearing old history data but that's not an option for us since we have obligations to keep the backup status for our customers (reviews and stuff)
When checking the SQL server we can see some massive load on the database (180mb/sec read at times) but i cant correlate the load to going in to the "Disk" view.

If anyone have similar issues please let me know.

/Nils

[foggy]

Nils, you seem to be the first to report this here on forums and in fact Update 3 was supposed to reduce load on SQL Server and improve Veeam B&R UI performance (and opening Backups node particularly). What SQL Server version are you using? Is it a local or remote DB?

[Nilsn]

Hi, i don't know if its because we have a quite large(atleast we think) Veeam installation with a lot of systems beeing backed up.
The DB is local, we upgraded the MS SQL 2014 Express version to a standard version yesterday to be absolutely certain that where not the problem and since that's the recommended setup for larger environments.
We can after the upgrade at least enter "Disk" view but it takes 3-5 minutes to get the view.
Trying to start a "Quick" backup is equally slow when right clicking the VM to start the quick backup.

After the upgrade the MS SQL Server is only using 175mb of ram, before express used up to 5,5gb (witch is weird since ms SQL express only support 1gb of ram per DB)
My guess is that the standard edition handles the sql query's in a more efficient way.
The server we run this on have 6 cores and 32gb ram.

As i understand it from the support tech there are some heavy SQL querys beeing done that take over 10 minutes to run (on the techs computer with a copy of our DB)

Where putting out all channels to get help in solving this since it hinders our production quite a bit, 24/7 shop that needs to be able to trigger backups before patching and such so quite critical for us.

[foggy]

Please continue working with your engineer. Also, since this behavior might be caused by the huge number of job sessions stored in the configuration database, even provided cleanup is not an option for you, I'd probably consider enabling some history retention.