Remember that w3wp consumes too much CPU (dictionary and Thread safety)

Since the launch of the project has been a more worrying problem, and a lack of confidence to deal with the bug, that is, when the application starts may cause the CPU to run 99% or continue in a value such as 50%, so the pressure on the server is very large, often the server can not remote state, The only way to solve this problem is to kill the corresponding w3wp process through PowerShell.

Why not have the confidence to deal with this problem

The reason is very simple, the problem is intermittent, not easy to reproduce, only when the project starts to have a certain likelihood of CPU run-up problem.

It's not too hard to handle all the bugs that can be reproduced, and a bug like this one that can't be reproduced is the most frustrating because it's no trace.

How to deal with this problem?

1. At the beginning of the use of guessing method, go to the project to find while, lock and other keywords, this is like a needle in a haystack, and not rigorous changes will lead to other more serious problems arise, and soon this program in the search has been abandoned.

2. Later remember to use WinDbg solved the problem of computer blue screen, it is possible to grasp the corresponding w3wp process dump for analysis.

Using WinDbg to find clues

1. Because the server is 2008r2 crawl dump becomes extremely simple.

2. Using WinDbg

View thread information after load SOS.dll.

Found that there are 7 threads more time-consuming, I thought I used the thread is also 7, the heart of the excitement.

Switch to 21 thread, view stack information and discover

When the dictionary insert is blocked, it's time to look at other long-running thread states, which is just as clogged.

Does the Insert method in the dictionary really clog?

Write down the following test code and run it several times.

It's true that at some point the CPU gets very high and sometimes it's normal.

Then the problem is clear, it becomes very easy to solve it, find the Getroutes code, the original is so implemented

Bundletable.bundles the internal maintenance of a static dictionary table, then the problem is out of the question, the code is locked.

The modified code

After observing for a period of time, the problem has indeed been solved.

Why is insert in dictionary blocked

I know that dictionary is not a thread-safe type, but I thought that the data would go awry without clogging or deadlock when dictionary was accessed in a non-thread-safe manner, and this time the problem surprised me, why does the Add item cause a blockage?

Anti-compilation dictionary source after the discovery of the complexity of the anomaly, there is no scrutiny, so the following paragraph describes people have their own ideas to read, may be wrong or may be right.

Above is where I think there is a problem, when a thread executes a initialize after the value of the buckets array is modified, and the second thread enters the Initialize method at the same time, the value maintained by the first thread is destroyed, resulting in a dead loop in the algorithm link, This can also explain why the CPU is sometimes 50% and sometimes 99% of the problem.

How many threads are currently present in this state, and the more threads that occur, the more CPU is consumed.

Written in the last

Since the beginning will not use WinDbg to find a technical group of Stevenchen help solve the problem, coincidentally, two people speculated that the problem here collided, here thanks to the next stevenchen.

Remember that w3wp consumes too much CPU (dictionary and Thread safety)