Eonetservice and ASP.NET w3wp Worker Process Memory Utilization
In the past few months, there has been an increase in memory utilization for eonetservice on some web servers. The symptom would show the controlling process on the web server machine (w3wp) showing increase in memory for each mobile device that synchronizes, each time it synchronizes.
When a handheld synchronizes using eonetservice, that ASP.NET application runs under an application pool on the web server. That application pool is controlled by a process named w3wp, so named when IIS6.0 split up the functionality between a web server (inetinfo, i.e. regular web pages) and a web service (processes such as eonetservice).
A web server, outfitted with the latest service packs from Microsoft, would see a gradual increase in memory utilization as each handheld synchronizes. In IIS7 (vista, windows server 2008), the increase would be quite dramatic. In some extreme cases, the customer would see each w3wp instance consume nearly 2 GIGAbytes of memory and not let go.
As in our other applications, eonetservice was quite diligent in releasing memory back to the system when it was complete with it. However, the most up-to-date Microsoft .NET library behaved differently for multiprocessor servers than single processor machines. The server garbage collector (which manages the system memory) was quite ‘lazy’ to release resources after they were used. In fact, by design, Microsoft had put in code to hang on to memory even after eonetservice was done with it.
Tell the asp.net w3wp process to more aggressively free up memory. We do that by modifying a specific file on the web server, Aspnet.config, which is located in the .net framework folder. You will find it here: C:\\Windows\Microsoft.NET\Framework\v2.0.50727
Even machines that are running .NET 3.5 SP1, utilize this folder for IIS ASP.NET configuration. In the file (aspnet.config on the web server), you will want to add the highlighted item:
This directs the w3wp process to utilize the non-server mode for the garbage collector.
The result is that w3wp process runs using the more efficient garbage collector for the asp.net process, and as a consequence, significantly reduces the memory footprint for eonetservice. In my tests it showed w3wp going from a maximum of 800Megabytes of memory utilization down to 40Mbytes total.
Testing has also shown that setting the non-server mode does not adversely affect eonetservice ability to scale to hundreds of handhelds.
The technical bulletin posted by Microsoft on this issue is located at this URL: http://support.microsoft.com/kb/911716
If you would like to read more about the garbage collection process, the section titled “Choosing Which Garbage Collector to Use” can be reviewed in this URL: http://msdn.microsoft.com/en-us/library/ms973838.aspx
For production systems (our customers running live), this file (aspnet.config) is safe to modify anytime. When doing so, application pools should be recycled so the asp.net worker process will read the new configuration (by either recycling manually in the IIS management console or killing the w3wp process in the task manager).
Technicians reviewing the windows 2008 IIS7 (or vista) eonetservice should include this modification to the asp.net config file and then examine memory utilization to validate the results from the development laboratory.