This article is the second in the series of Systrace articles, mainly to explain some preliminary knowledge of Systrace analysis, with these preliminary knowledge, analysis of Systrace will get twice the result with half the effort, faster and more efficient to find the problem point. This article introduced how to view the thread state in Systrace, how to analyze the wake up information of the process, how to interpret the data in the information area, and introduced the common shortcut keys. By studying this article, you will be able to learn some information about processes and threads, and how to view the key information contained in complex Systrace
Series of articles
- Systrace profile
- Systrace Basics – Systrace prep
- Systrace Basics – Why 60 FPS?
- Systrace basic knowledge – SystemServer interpretation
- Systrace Basics – SurfaceFlinger interpretation
- Systrace Basics – Input interpretation
- Systrace basics – Vsync interpretation
- Systrace Basics – Vsync-App: Choreographer based Rendering mechanics in detail
- Systrace Basics – MainThread and RenderThread interpretation
- Systrace Basics – Binder and lock competition interpretation
- Systrace Basics – Triple Buffer interpretation
- Systrace Basics – CPU Info interpretation
The body of the
Thread status Viewing
Systrace identifies different thread states in different colors, and above each method there is a corresponding thread state that identifies the current thread state. By looking at thread states we can see what the bottleneck is. Is it CPU slow, Binder calls, I/O operations, or not getting CPU time chips
There are several main thread states
Green: Running
Only processes in this state can run on the CPU. Multiple processes may be in an executable state at the same time, and their task_struct structures (process control blocks) are placed in the corresponding CPU’s executable queue (a process can only appear in one CPU’s executable queue). The task of the process scheduler is to select a process from each CPU’s executable queue to run on that CPU.
Functions: We often check the Running time of the thread in the Running state, compare it with the competing product, and analyze the causes of the fast or slow:
- Is there not enough frequency?
- Is it running on the nucleus?
- Do you switch between Running and Runnable frequently? Why is that?
- Do you switch between Running and Sleep frequently? Why is that?
- Was it on the wrong core? For example, unimportant threads occupy a hypercore
Blue: Running
The thread can run but is not currently scheduled, waiting for CPU scheduling
The longer the duration of the Runnable thread, the busier the CPU is.
- Are there too many tasks running in the background?
- Was it not handled in time because of the low frequency?
- Did not process in time because it was limited to a CPUSET and the CPU was full?
- What is Running’s task at this point? Why is that?
White: Hibernating
The thread has no work to do, probably because the thread is blocked on the mutex.
Function: Here is generally waiting for the event driven
Orange: Uninterruptible sleep IO Block
If a thread is blocked on I/O or waiting for a disk operation to complete, the bottom line identifies the callsite wait_on_page_locked_killable
Function: This generally indicates that IO operation is slow. If there is a large amount of orange uninterruptible sleep state, it is generally due to entering a low memory state. A pageFault is triggered when a memory request is made. In Linux, some pages in the page cache list are not ready (that is, the contents of the disk are not fully read). Wait_on_page_locked_killable is blocked when the user attempts to access the page. Only when the system is busy with I/O operations and each I/O operation needs to be queued, it is very easy to occur and the blocking time is long.
Purple: Uninterruptible sleep
The thread is blocked on another kernel operation (usually memory management, non-IO operation).
Function: generally, it is trapped in the kernel state. In some cases, it is normal, and in some cases, it is abnormal. It needs to be analyzed according to the specific situation
Process wake up information analysis
Systrace identifies a very useful piece of information to help with cross-process invocation-related analysis.
The information that a process is woken up is often very important. Knowing who it is woken up by, we can know the call waiting relationship between them. If there is a long sleep and then it is woken up, we can see who woke up the thread, and the corresponding information of the wakeup person can be seen. Find out why the awakeners are waking up so late.
A common situation is: Application processes use the Binder to communicate with SystemServer’s AMS thread, but if the AMS function is waiting for a lock to be released (or if the AMS function itself is running for a long time), the application process will have to wait for a long time. Performance issues, such as slow response or stuttering, can occur, which is one of the main reasons why there are a lot of processes running in the background, or performance deteriorates after Monkey runs.
One reason why Systrace can mark this is that a task will enter the Runnable state for waiting before entering the Running state, and Systrace will mark this state on Systrace (very short, need to zoom in to see).
Pull to the top and view the TAKS information on the corresponding CPU to identify the status of the task before it was woken up:
By the way, post some common Linux process states
- D The sleep state that cannot be interrupted (usually IO processes);
- R is waiting to be scheduled in the runnable queue;
- S is in the dormant state;
- T stop or be tracked;
- W into memory swap (invalid from kernel 2.6);
- X dead processes (almost rare);
- Z Zombie process;
- < high-priority processes
- N Processes with a lower priority
- L Some pages are locked into memory;
- The leader of the S process (there are child processes below it);
- L Multi-process (using clone_threads, similar to NPTL pthreads);
-
- A group of processes in the background;
Information area data parsing
Process status information parsing
Function Slice information parsing
Counter Sample information parsing
Async Slice information parsing
CPU Slice information parsing
User Expectation information parsing
The top part of Systrace identifies Rendering Response and Input Response
Shortcut key use
Shortcuts can be used to speed up your view of Systrace. Here are some common shortcuts
- W: Zoom in on Systrace to see local details better
- S: Zoom out Systrace, zoom out to see the whole
- A: left
- D: moves to the right
- M: Highlight the segment that the mouse is currently clicking on.
The default value is 1, that is, select mode. When viewing Systrace, you need to switch between different modes frequently. Therefore, the efficiency of clicking the switching mode is relatively low, while the efficiency of directly switching the mode is much higher
- “Number key 1” : Switch to Selection mode. In this mode, you can click a section to view its detailed information. Systrace is generally opened in this mode by default and is also the most commonly used mode
- “Number key 2” : Switch to Pan mode, this mode can drag left and right by holding down the mouse, sometimes used
- “Number key 3” : Switch to Zoom mode, which is used to Zoom in and out by holding down the mouse
- “Digit key 4” : Switches to Timing mode. This mode is mainly used to measure time, such as selecting a starting point and an end point, and viewing the operation time between the starting point and end point.
This article knows the address
Since it is not convenient to exchange blog comments, you can go to the zhihu interface of this article to like or communicate
Zhihu – Basic Knowledge of Systrace – Analysis of Systrace preparatory knowledge
About my && blog
-
- About me, I really hope to communicate with you and make progress together.
-
- Blog Content navigation
-
- Excellent Blog Post record – Android performance optimization is a must
“A person can go faster, a group can go farther“
This article is formatted using MDNICE