[BUG] IIS Express Worker Process use up to 26 GB memory while startup OqtaneFramework in Debug mode

[beolafsen]

Oqtane Info

Version - 6.0.0 but same problem with earlier versions
Render Mode - Static / Interactive
Interactivity - Server / Server
Database - SQL Server

Describe the bug

When I startup my Oqtane application the IIS Express Worker Process start to grow up to 26 GB memory. After a while I get problems with the Client/Server connection. Then the memory usage drops (in IIS Express Worker Process) and after a while I get the connections again and then it starts to build up the memory usage. And this loop continue.

To find out where the problem comes from, I tried to only work with the original OqtaneFramwork application.
First I tried to reproduse the same error with OqtaneFramework - and the same happens - the memory usage go up to 26 GB.

After this I deleted the bin directory in OqtaneFramework and the I compiled the OqtaneFramework before I run it. Then I don't get the problem with memory.

Then I compile my Oqtane application (with copy of DLL's to OqtaneFramework) - and then I start the OqtaneFramework application again and then I got the same problem with memory usage.

It looks like my Oqtane Server DLL is causing some problem even though I'm only running a pure OqtaneFramework application.

Any ideas on what could be the problem?

Div pictures:

[beolafsen]

Video of startup Oqtane Framework.

recording (2).zip

[beolafsen]

The problem started when I upgraded from VS 17.10.6 to 17.11.5.

[beolafsen]

Then I tried to upgrade to VS 17.12.0 and 17.13.0-Preview 1.0 but I have the same problem with the memory.
Then I went back and installed VS 17.10.6 again and the problem disappeared.
Any ideas?

[sbwalker]

I have noticed that when running Oqtane in the Visual Studio debugger the memory allocation is quite high and it increases as you navigate around the application. This behavior is very different from the way Oqtane runs in production so it seems to be related to Visual Studio. In fact I experience the same behavior with any Blazor application in Visual Studio - not just Oqtane.

[beolafsen]

The problem here is that it only takes about 2 minutes from when I press RUN DEBUG until IIS Express Worker Process has allocated 26GB of memory. And in those 2 minutes, I haven't navigated or done anything else in the application. Only waited.

Since this is a problem that happened after upgrading VS 2022, I also think that it is a problem with VS. At the same time, I wonder if it could also be something with Oqtane since it only happens when my OqtaneLibrary.Server.dll is placed in the Oqtane.Server directory (even though I am not running my Oqtane version - only Oqtane Framwork). What is Oqtane doing with the DLLs that are in the BIN catalog?
I have reported this issue to VS Community - but without response.

[leigh-pointer]

Kestral runs faster!

[beolafsen]

Yes - but the result is the same regarding memory allocation.

This is how it is when I use VS version 17-10-6

[sbwalker]

Oqtane is a modular framework which means it needs to load assemblies which are part of the Oqtane environment into the app domain during startup. It uses a file naming convention to determine which assemblies in the /bin need to be loaded. If an assembly contains the term "oqtane" then it is loaded:

        public static bool IsOqtaneAssembly(this FileInfo fileInfo)
        {
            return (fileInfo.Name.Contains("oqtane", StringComparison.OrdinalIgnoreCase));
        }

Oqtane has followed this approach since version 1.0, as it is simple and performs very well (ie. it targets a subset of assemblies and does not need to use reflection or other expensive operations to inspect the assemblies).

So if you have a custom assembly named OqtaneLibrary.Server.dll then it will be loaded during startup. And if this assembly is very large then it will consume a lot of RAM. If this assembly should not be loaded then you would want to give it a different name. Generally the recommended approach is to name assemblies so that they reflect their owner and purpose ie. YourCompany.Library.Server.dll

[beolafsen]

Thank you - I will change this just to be sure, but my DLL's are in KB, not in GB, so I don't think that is the case. It has worked fine until the upgrade of VS. Problem now is that the VS version that I can use (v 17.10.6) can not run .net9.0 so I have to wait with the upgrade of Oqtane until this is solved. Med vennlig hilsen Bjørn-Even Olafsen

[beolafsen]

Is there any restrictions on the namespace names?

ex: @namespace OqtaneLibrary.AuditListe

[sbwalker]

Assemblies are loaded based on the file naming convention I explained above - not namespace.

Note that Oqtane also loads satellite assemblies (ie. *.resources.dll) if they exist. Does your custom module have large satellite assemblies?

This problem seems to be specific to your environment, as I am unable to reproduce it locally. So at this point there is nothing in Oqtane which could be "fixed" to resolve your problem.

[sbwalker]

Also note that if the assembly being loaded has dependencies, Oqtane will load them as well (assuming they exist in the /bin folder). So if your custom library has large dependencies then they could consume a lot of RAM.

[beolafsen]

Now - I don't have large DLL's. OK - thank you for looking into it. Best regards Bjørn-Even Olafsen