Shulou(Shulou.com)06/02 Report--

How to find the reasons for the rising memory of .NET programs, in view of this problem, this article introduces the corresponding analysis and solutions in detail, hoping to help more partners who want to solve this problem to find a more simple and easy way.

Some time ago, the company's newly written automatic upgrade server (Remoting) showed a continuous surge of memory, which soared to more than 1G from the initial 70 trillion one night, which directly led to the failure of the client connection server, which was unscientific. Later, it optimized various methods that may cause memory consumption (database connection, Icano operation, reference type release), but the effect was not good, which can be difficult for us. If you don't know what the problem is, you don't know how to fix it.

We know that .NET has a garbage collection mechanism, which is usually caused by some data that lives in memory for a long time and cannot be regarded as garbage collection.

Later, a variety of searches were conducted on various search engines, some said to use windebug to analyze dump, but it took a lot of time to figure out whether it was a hardware problem or poisoning. * found a CLRProfiler tool released by Microsoft, which seemed to be very powerful, so it was MSDN. MSDN said:

Who allocates what on the managed heap.

Which objects survive on the managed heap.

Who is holding on to objects.

What the garbage collector does over the lifetime of your application.

After getting this information, I decided to use it, let the server run for a while, stop to get the analysis results, and finally learned in the Allocation Graph view that it was caused by the byte [] array under the DownloadFile method of downloading files, and it took up more than 200 megabytes of memory in less than a minute. Well, now we can find the "original culprit" and have to toss about.

Solution 1: load the data to be downloaded into memory at the same time, and users can obtain byte through position when downloading. [] if you don't build a new file and return it directly, it can solve the problem, but this greatly reduces the availability of the server. It can only be used as a small file server, which is too unreasonable.

Option 2: since a serializable class is returned when downloading the file, if there is a problem here, you can directly return to byte [] and implement it with the most basic data header-> data length-> data tail. But in this way, there are too many things to change, the server client side, the protocol reconfiguration, and the project that is about to end, but you are reluctant to start all over again. In addition, there are a lot of tasks behind, this is not to cheat themselves, but also give up.

Then back to a variety of network information search, after a search, learned that byte [] will eventually be recycled, as long as the managed data can be recycled, but the cycle may be longer, * * returned to the Remoting itself, with the mentality of trying to change WellKnowObjectMode from SingleTon to SingleCall, running overnight * stable at around 200m, finally relieved.

Using SingleTon was intended to save memory consumption, but I didn't expect that the loss outweighed the expense, so I concluded that SingleTon is not suitable for server programs with large concurrency. SingleTon is a single-threaded mode, which will be locked when each method is called. Guess that the reason why the data can not be released is caused by these locks. Because there are too many connections, the connection has been queued. Resulting in the later connection of the client response is too slow, connection timeout, here also give you a lesson or to use SingleCall reality.

What has been said above is just to share with you the experience of solving the problem, and to describe where the problem lies. If you have different opinions, please be sure to point it out. After all, .NET memory allocation and garbage collection are more complicated.

However, things went against one's wishes, but the willows and flowers were bright.

The focus of this article is on how to use CLRProfiler to find out the memory allocation of .NET programs, so let's start.

Download CLR Profiler: http://search.microsoft.com/en-us/DownloadResults.aspx?q=clr%20profiler

You can download the corresponding CLRProfiler according to your own version of .NET. Take .NET 4.0 as an example below. CLRProfiler can analyze applications, services and programs written by ASP.NET. Here is an example of how to simply use CLRProfiler.

The following is an example of unpacking CLRProfilerTestDemo, which is used to observe the allocation of the process managed heap and to study the behavior of the garbage collection mechanism. The code is as follows

Using System; using System.Collections.Generic; namespace CLRProfilerTestDemo {class Program {static void Main (string [] args) {for (int I = 0; I < 100 * 1000; iTunes +) {Boxing box = new Boxing ();} Environment.Exit (Environment.ExitCode) }} class Boxing {private List box = new List (); private List unbox = new List (); public Boxing () {for (int I = 0; I < 1000; iTunes +) {box.Add (I); unbox.Add ((int) box [I]) }}

Run CLRProfiler, and select the Allocation and Calls options as shown below:

Compile the program, click Start Application to select CLRProfilerTestDemo.exe, will run the program, after running for a period of time, click Kill Application,CLRProfiler will display the analysis results.

Open the Allocated bytes histogram interface, as shown in the following figure, and you can find the suspicious class Boxing in the allocation type area on the right

Here is the Allocation Graph memory allocation view, in which we can see how the stack separates objects.

Use the CLRProfiler tool to do these simple steps to find out the source of the surge in application memory and find ways to fix it.

This is the answer to the question about how to find the reasons for the rising memory of .NET programs. I hope the above content can be of some help to you, if you still have a lot of doubts to be solved. You can follow the industry information channel for more related knowledge.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.