Symptoms: ActiveReports is consuming too much memory and the CPU usage is at 100%.

There are several reasons why too much memory may be consumed:

---

Cause: The report is not being disposed of properly. The incorrect syntax is as follows. 

[Visual Basic.NET]
rpt.Dispose()
rpt=Nothing
[C#]
rpt.Dispose();
rpt=null;

Solution: The correct syntax for disposing of a report properly is as follows. 

[Visual Basic.NET]
rpt.Document.Dispose()
rpt.Dispose()
rpt=Nothing

[C#]
rpt.Document.Dispose();
rpt.Dispose();
rpt=null;

---

Cause: Large reports in an ASP.NET application can easily use up the 60% of memory allocated to the ASP.NET worker process by default, which produces an error. In Machine.Config, MemoryLimit specifies the maximum allowed memory size, as a percentage of total system memory, that the worker process can consume before ASP.NET launches a new process and reassigns existing requests.

Solution: Set the CacheToDisk property of the document to True.  This will cache the report to disk instead of holding it in memory. This setting is also detected by the PDF Export, which will follow suit, but any other exports will still consume memory. Although it is not advised, the ASP.NET worker process memory allocation can also be changed in your Machine.Config file, which is located in a path like: C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\CONFIG\.  Search the Machine.Config file for memoryLimit which is located in the processModel.

---

Cause: In some cases, very large reports can consume so much memory that the report never finishes processing. Some of the things that can cause this include:

1. The use of many non-repeating images, or a high resolution repeating image
2. Instantiating a new instance of a subreport each time the format event of a section fires
3. Using a lot of subreports instead of grouping by doing joins in the SQL query
4. Pulling in all of the data when only a few fields are needed, i.e. Select * from db instead of Select First, Last, Address from db

Solution: In cases where the report is too large to run any other way, the CacheToDisk property may be set to True. This property should only be used when there is no other way to run the report to completion. Before resorting to this method, please see the Optimizing ActiveReports topic.

---

Cause: If inflated memory usage is seen in the Task Manager it is not necessarily in use by the code. Task manager indicates the current "working set" of the process and, upon request, other processes can gain access to that memory. It is managed by the OS.

Solution: For an example of some working set behavior anomalies (which are considered normal), create a WinForms application and run it. Look in Task Manager at the working set for that process (it should be several megabytes), then minimize and maximize the form and notice that the working set reclaims to <1MB. Obviously, the code was not using all that memory even though Task Manager showed that it was allocated to that process. Similarly, you'll see ASP.NET and other managed service processes continue to gradually grow their working set even though the managed code in that process is not using all of it. To see whether this is the case, try using the two lines of code below under a button after running the project.

System.Diagnostics.Process pc = System.Diagnostics.Process.GetCurrentProcess();
pc.MaxWorkingSet = pc.MinWorkingSet;

If that reclaims the memory then the OS trimmed the working set down to the minimum amount necessary and this indicates that the extra memory was not actually in use.

---

See Also

 

 

---

Copyright © 2004-2007 Data Dynamics, Ltd. All rights reserved.