I've recently started moved my Umbraco (mostly 4.5 with .NET 3.5 web.config) websites from a Win2k3 server with IIS6 & .NET 3.5 to a Win2k8 Datacenter Edition server with IIS7 & .NET 4 installed.
No problem with my old websites, they continue to run as before.
However, I'm just developping a new Umbraco Juno 4.6.1 website on the .NET 4 platform. And, although, I'm still in development, I already notice big memory issues : Whereas my old Umbraco 4.5 websites consume about 100k memory (private bytes) and about 600k virtual size, the new Umbraco Juno 4.6.1 already consumes about 150-200k memory (with peaks up to 600k) and about 5 to 6 MB virtual size! What's particularly strange according to me : even when I recycle the application pool, it only takes a couple of seconds before it reaches the above amounts of memory use again.
I'm not entirely sure if that excessive memory is caused by the new Umbraco version (4.6 as opposed to 4.5), or the ASP.NET version I'm using (4.0 as opposed to 3.5).
In the process of installing Umbraco 4.6.1, I first had to remove the following lines from my web.config ("system.web" - "compilation" - "assemblies" section) before I could configure my website in IIS7 without errors (.NET Compilation screen) :
Apparently, these lines were already included in the machine-level web.config. I thought that was odd already : why would Umbraco provide a .NET 4 web.config with lines that weren't compatible with the default .NET 4 settings?
After that, I got an error in Helicon APE manager until I threw out this other following line :
Unusual memory peaks with Umbraco Juno 4.6 (on Win2k8 Datacenter edition w./ ASP.NET 4.0)
I've recently started moved my Umbraco (mostly 4.5 with .NET 3.5 web.config) websites from a Win2k3 server with IIS6 & .NET 3.5 to a Win2k8 Datacenter Edition server with IIS7 & .NET 4 installed.
No problem with my old websites, they continue to run as before.
However, I'm just developping a new Umbraco Juno 4.6.1 website on the .NET 4 platform. And, although, I'm still in development, I already notice big memory issues :
Whereas my old Umbraco 4.5 websites consume about 100k memory (private bytes) and about 600k virtual size, the new Umbraco Juno 4.6.1 already consumes about 150-200k memory (with peaks up to 600k) and about 5 to 6 MB virtual size!
What's particularly strange according to me : even when I recycle the application pool, it only takes a couple of seconds before it reaches the above amounts of memory use again.
I'm not entirely sure if that excessive memory is caused by the new Umbraco version (4.6 as opposed to 4.5), or the ASP.NET version I'm using (4.0 as opposed to 3.5).
In the process of installing Umbraco 4.6.1, I first had to remove the following lines from my web.config ("system.web" - "compilation" - "assemblies" section) before I could configure my website in IIS7 without errors (.NET Compilation screen) :
<add assembly="System.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" />
<add assembly="System.Xml.Linq, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" />
<add assembly="System.Web.Extensions, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
<add assembly="System.Data.DataSetExtensions, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" />
Apparently, these lines were already included in the machine-level web.config. I thought that was odd already : why would Umbraco provide a .NET 4 web.config with lines that weren't compatible with the default .NET 4 settings?
After that, I got an error in Helicon APE manager until I threw out this other following line :
<!-- ASPNETAJAX -->
<system.web.extensions>
<scripting>
<scriptResourceHandler enableCompression="true" enableCaching="true" />
</scripting>
</system.web.extensions>
I urgently need help on this, because my memory limits are daily reached
Did you manage to get to the source of this issue? We are running 4.6.1 and are experiencing a similar issue.
4.6.1 had some major issues which are fixed in 4.7.0. Perhaps this problem is also fixed.
Jeroen
is working on a reply...