The server memory is too small to hurt! [Chain murder case caused by exceptions and application pool]

I have been writingAnalysis of Technical Principles of the autumn GardenIn this article, I will write a prose article to briefly describe the murder case caused by a small server memory.

 

In the past, all the texts were typeset. This article is a prose article. After writing the article, I will add the blacklist and the red text.

 

First, I will first upload two pictures of the current process and memory of the autumn garden Server:

 

1: Process

 

2: remaining physical memory

 

After reading these two images, what do you think?Insufficient memory !!!!

 

Poor, nervous, or even tight. What is the problem?

 

An accident has occurred. The application pool will generate a recycle action !!!!

 

First, let's take a look at what happens in the application pool to reclaim the app pool?

 

1: The configuration in "recycle" in the IIS application pool will not be mentioned. These are your own definitions.

2: manually execute "recycle" to restart the application pool.

3: When you upgrade the dll to the server, the new upgrade will cause the application pool to restart.

4: The web application generates an "error" and the process is terminated, causing the application pool to restart.

5: I cannot figure it out ......

 

 

What happened?

 

The memory is not too tight. To demonstrate something, I decided to recycle the application pool for everyone !!!

 

Here, the example of this machine is recycled. Everyone knows what is going on. Haha:

 

See, what are the two processes?

IIS enables a new process to receive new requests. At the same time, the old process requests will be retained to the Request queue before they are processed until all previous requests are processed.

This is basically the case. The problem arises at this moment:

There was no memory, the old process was not recycled, and the new process came out again. As soon as it came out, it shouted for memory, but the system could not provide the memory, so it got stuck there, it also causes CPU usage.

In this small room, website access gets stuck and cannot be opened, giving you a feeling of slow speed.

 

When do you feel open? It is estimated that the old process is glorious and retired.

 

Well, there are not many situations during the upgrade, and the application pool is set to be recycled only once in the middle of the night. Theoretically, there are not many collections, and there is not much chance of such a small instant.

 

However, website Instability occurs frequently, and it seems that it exceeds the configured time and upgrade frequency.

 

Just these days, I found that my infrastructure is a little poor:

The web application generates an "error" and the process is terminated, causing the application pool to restart.

I haven't paid much attention before. Now I find that the application pool will be restarted frequently due to poor code writing and handling exceptions, which is also a cause of slow website speed.

 

Cut a picture for everyone:

 

If you see a bunch of errors and warnings on your server, it means you are just as basic as you are.

 

How are these logs generated?

 

In fact, it is the exception that the system has not captured, and then it finally passes through the five levels, and finally it runs here, basically, your application pool becomes unstable.

 

Let's talk about the exception at will.

The first point is:

In. NET 2.0, errors of the main thread or thread will lead to process suspension and application pool collection.

In Version 1.1, thread errors do not cause the master process to stop.

 

PS: Remember my previous article"Analysis of QBlog technical principles of the autumn color Park: Performance Optimization: user and article counter solution (17)"Built-in threads,

In fact, this problem is hidden. thread access conflicts often lead to the suspension of the main process and restart the application pool.

 

Let's talk about the following:

First, handle the warnings and exceptions in the log.

 

The last point is:

Capture unhandled exceptions globally and then delete them, Do not let it run here to endanger application pool restart . [Supplement: setting it does not prevent application pool restart.]

 

The infrastructure is not good. After many days, I accidentally discovered such code:

I. AppDomain. CurrentDomain. UnhandledException event

Public Window1 (){
InitializeComponent ();
AppDomain. CurrentDomain. UnhandledException + = new UnhandledExceptionEventHandler (CurrentDomain_UnhandledException );
}

Void CurrentDomain_UnhandledException (object sender, UnhandledExceptionEventArgs e)
{
Throw new NotImplementedException ();
}

PS: it seems that this guy does not work in the web, and does not get deeply entangled in it, and it cannot prevent exceptions from being reported. It can only be used to collect information.

 

Ii. HttpApplication. Error Event

Public void Init (HttpApplication context)
{
Context. BeginRequest + = new EventHandler (context_BeginRequest );
Context. Error + = new EventHandler (context_Error );
}

Void context_Error (object sender, EventArgs e)
{
HttpApplication app = (HttpApplication) sender;
Log. WriteLogToTxt (app. Server. GetLastError ());
App. Server. ClearError (); // eliminates errors and prevents them from being thrown up.
}

 

The app. Server. ClearError () is actually mentioned here. To find this line of code, I had to struggle for several hours and found it by chance ,[Although I found it, it does not seem to have much effect].

 

Supplement:

I tested the problem and got the following results:

1: The "error" generated in the main line. As long as it is not fatal, the system log is only at the "warning" level and will not cause application restart.

2: The "error" generated in the built-in thread, the "error" level generated in the system, it will stop the process, and the above global statements cannot catch exceptions.

 

Of course, there are several questions:

1: Will an application pool be terminated and restarted only when it encounters an "error" level?

2: The Common Errors in the main thread are "warning". Is there any possibility of "error" errors?If yes, can it be intercepted? Is the above Code for clearing exceptions valid?

3: why are there no global events for exceptions in multiple threads?If so, where are you?

 

 

Now, basically all errors are recorded,Step by step, the logs are eliminated one by one. Now the application pool is basically stable and will not be restarted, which is much more secure.

 

In fact, the following is a summary:The memory is too small to hurt!