“This is the 8th day of my participation in the Gwen Challenge in November. Check out the details: The Last Gwen Challenge in 2021”
preface
The ability to locate quickly is very important to those doing performance analysis. Peel off layers, don’t jump. Recently I’ve seen a lot of people doing performance problem solving on projects that rely on cheating. Like adding threads like crazy.
Phenomenon of the problem
A recent phenomenon that emerged in a system tested was this. (I am not going to go into detail this time, but just say the overall idea, because the means of operation used have been explained in my previous article).
Let’s look at a couple of pictures.
As you can see from the graph above, the system clearly has a performance bottleneck (if anyone asks why, I don’t think it does performance).
What happens when this happens? Of course, I wanted to know what was wrong with the back end, so I looked at each of the relevant systems and saw the following.
System-level information:
Soft interrupt, soft interrupt, soft interrupt. Now you can start to worry about the application. Let’s keep going. When you switch to threads, you see something like this.
And then there’s the old idea. Print out the stack information and take a peek.
The cause of this problem is actually a memory parameter configuration error. Don’t mention it.
There’s a lot of time in performance issues where we’re wrestling with this kind of human error.
conclusion
This article is intended to illustrate the thinking behind this analysis, and all of the tools used are covered in my previous article.
For performance analysis, clarity is much more important, much more important, than just doing it. Otherwise we are constantly wasting our time and the time of others.