My sharepoint webpart with the webchart is working very nicely. So I decided to do some load testing using VS2005 loading testing tools. I then found that the w3wp process had a memory leak when I ran the test at 100 users for 3 min.
I then tried to isolate the problem and created a simple web page with just the chart control (no webpart or sharepoint) and no data source and found that the WebDev.WebServer.exe (the w3wp equivalent) leaked 22Meg in 3min at 100 user load.
This leak would equate to 10gig over a 24 hour period at 100 user load.
Is there a known issue with a memory leak of the WebChart control? Is a 100 user load generated by VS2005 a realistic load? Is there something that I am doing wrong?
Cheers,Jim
After futher testing, it looks like there is always a leak when performing the vs2005 load testing even for a blank page? Maybe it is IIS???
i would guess it's ASP.NET, not IIS, that's leaking memory. fortunately, ASP.NET is protected from memory leaks because it will terminate the process and restart periodically if the memory usage gets too high.
i don't know about VS2005's load test tools as memory profilers, though. you might want to temporarily add a call to GC.Collect in your Page_Load to make sure garbage collection is occurring-- because you can't really profile memory leaks effectively without running GC every time you evaluate memory usage.
An update on memory leak!
Running at lower loads (up to 20 users) I ran a load test 3 times for a duration of 3 min each and found that w3wp went from 230Meg to 920Meg (700meg over 9min). When I removed the infragistics webpart from the page it only leaked abut 30Meg.
I used the Debug Diagnostic tool on w3wp.exe and found the following difference to the non webchart page:
mscorwks.dll (a known Windows memory manager) is responsible for 258.92 MBytes worth of outstanding allocations
and
GdiPlus.dll is responsible for 148.17 MBytes worth of outstanding allocations.
The call stack for the GDI usage was as follows:
Function Source Destination GdiPlus!GpMemoryBitmap::AllocBitmapData+71 kernel32!VirtualAlloc GdiPlus!GpMemoryBitmap::AllocBitmapMemory+26 GdiPlus!GpMemoryBitmap::AllocBitmapData GdiPlus!GpMemoryBitmap::InitNewBitmap+49 GdiPlus!GpMemoryBitmap::AllocBitmapMemory GdiPlus!CopyOnWriteBitmap::CopyOnWriteBitmap+4c GdiPlus!GpMemoryBitmap::InitNewBitmap GdiPlus!CopyOnWriteBitmap::Create+23 GdiPlus!CopyOnWriteBitmap::CopyOnWriteBitmap GdiPlus!GpBitmap::GpBitmap+32 GdiPlus!CopyOnWriteBitmap::Create GdiPlus!GdipCreateBitmapFromScan0+c2 GdiPlus!GpBitmap::GpBitmap System.Drawing.Bitmap..ctor(Int32, Int32, System.Drawing.Imaging.PixelFormat) 0x7AEBA558 Infragistics.UltraChart.Render.ChartRender.CreateChartBitmap(Int32, Int32) 0x7AEBABF4 Infragistics.UltraChart.Render.ChartRender.RenderChart(Infragistics.UltraChart.Core.SceneGraph, System.Drawing.Size, System.Drawing.SizeF) Infragistics.UltraChart.Render.ChartRender.CreateChartBitmap(Int32, Int32) Infragistics.UltraChart.Render.ChartRender.RenderChart(Infragistics.UltraChart.Core.SceneGraph, Int32, Int32) Infragistics.UltraChart.Render.ChartRender.RenderChart(Infragistics.UltraChart.Core.SceneGraph, System.Drawing.Size, System.Drawing.SizeF) Infragistics.WebUI.UltraWebChart.UltraChart.Render(System.Web.UI.HtmlTextWriter) Infragistics.UltraChart.Render.ChartRender.RenderChart(Infragistics.UltraChart.Core.SceneGraph, Int32, Int32) System.Web.UI.Control.RenderControlInternal(System.Web.UI.HtmlTextWriter, System.Web.UI.Adapters.ControlAdapter) System.Web.UI.Control.RenderControl(System.Web.UI.HtmlTextWriter, System.Web.UI.Adapters.ControlAdapter) System.Web.UI.Control.RenderControlInternal(System.Web.UI.HtmlTextWriter, System.Web.UI.Adapters.ControlAdapter) System.Web.UI.Control.RenderControl(System.Web.UI.HtmlTextWriter)
I researched the gdi error leak and found a knowledge base article: Memory Leak in .NET Managed Usercontrols http://support.microsoft.com/kb/555916
Have you guys (Infragistics) tested the WebChart under loads?
Also, I will do some more tests with your above recommendations.
we have load tested the webchart, but usually not with memory profiling in mind. typically when we search for memory leaks, we use one instance of the control and one browser.
the bitmap in the call stack you cite should be disposed. but one of my colleagues who saw this post just pointed out one bitmap that we create which does not get disposed -- so we will be fixing that for an upcoming hotfix (pending a bit more investigation on our part).