Performance Analysis _linux Server CPU_CPU utilization

CPU Metrics

1. Indicator Range 1.1 User mode CPU utilization+ System Mode CPU Utilization

Reasonable value: 60-85%, if the us+sy time in a multiuser system exceeds 85%, the process may take time to wait in the running queue, the response time and business throughput will be compromised; the US is too large to indicate that there is a user process that consumes a lot of CPU time, and further analysis of other hardware and software factors is required; sy too large , it shows that the system management has spent a lot of time, indicating that a subsystem in the system has a bottleneck and needs further analysis of other hardware and software factors.

1.2 Wa (Wait)

Reference value: Less than 25%, the value of more than 25% WA can indicate that the disk subsystem may not be properly balanced, or it may be the result of a disk-intensive workload, a system disk or other I/O may have problems, can be further decomposed by the IOSTAT/SAR–C command analysis

1.3 Id (Idle)

Reference value: Greater than 40, if R is often greater than 4, and the ID is often less than 40, indicating a heavy load on the CPU

1.4 R

Reference value: Less than 4, the queue is greater than 4 o'clock, indicates that the system CPU or memory may be a problem, if R is often greater than 4, and the ID is often less than 40, indicating that the CPU load is heavy. When the queue becomes longer, the process in the queue takes longer to wait for the CPU to schedule execution

1.5 ways to determine CPU bottlenecks

Very slow response times (slow response time)

CPU idle time is 0 (zero percent idle CPU)

Excessive user consumption CPU time (high percent user CPU)

Excessive CPU time (high percent system CPU)

Long running process queue (large run queue size sustained over time)

2. How to view CPU Utilization 2.1 Use the top command to view

Data from/proc/stat file

%us = (User time + nice times)/cpu *100%

%sy= (System time + HARDIRQ)/CPU times *100%

%id= (Idle)/cpu time *100%

%ni= (Nice time)/cpu *100%

%wa= (Waiting time)/cpu *100%

%hi= (Hardirq time)/cpu *100%

%si= (Softirq time)/cpu *100%

%st= (Steal time)/cpu *100%

Note: The top command is refreshed every 3 seconds by default. You can also specify the refresh frequency, such as top-d 0.1 or top-d 0.01, by top-d < refresh interval >. When top is executed, you can also press the "s" key to modify the time interval.

2.2 Using Vmstat to view

R indicates the size of the running queue, B indicates the number of threads in the block due to Io waits, in represents the number of interrupts, and CS represents the number of context switches.

2.3 Other ways to view

Iostat, Sar-q, sar–u, etc.

3. CPU Introduction 3.1 time in the kernel

Hz is the number of times the system clock is fixed to make a clock interrupt within one second. Hz can be configured before compiling the kernel, so you can see the current system's clock interrupt frequency with the following command: cat/boot/config-' uname-r ' | grep config_hz

Tick is the time that the system clock ticks every tick, with a value of (1/hz) seconds. That is, the time interval between two consecutive clock interrupts.

The jiffies is used to calculate the number of ticks since the start of the system, which means that the value of the variable is incremented once each time the clock is interrupted by the system clock.

3.2 CPU Time composition

The working time of CPU is composed of three parts: User state time, System state time and idle state time. The specific composition is:

The CPU time includes user, System, nice, Idle, waiting, HARDIRQ, SOFTIRQ, Steal

Idle state ==idle Time

User state time ==user time+ nice times.

Kernel state time ==system time+ HARDIRQ time+ SOFTIRQ.

User Time. Refers to the time that the CPU executes the process in the user state.

System time. Refers to the time that the CPU is running in the kernel.

Nice time. Refers to the time that the system spends adjusting the process priority.

Idle time. The system is in an idle period and waits for the process to run.

Waiting time. The total time that the CPU spends waiting for I/O operations, similar to blocked.

Steal time. Refers to the amount of time that the current CPU is forced (involuntary wait) to wait for another virtual CPU to finish processing, at which point Hypervisor is serving another.

Softirq time, Hardirq time. Corresponds to the CPU time that the system spends dealing with soft and hard interrupts, respectively.

3.3 User Mode CPU utilization

%usr. Shows the percentage of CPU time that is spent in the user's way, the process by which the user uses the CPU: the CPU runs a regular user process, and the CPU runs niced PROCESS,CPU runs the real-time process. A Linux process can be executed in the user mode, or in the system (kernel) mode, when a process runs in kernel code, we call it in the kernel state, when a process is executing the user's own code, we call it in the user state, when executed in user mode, The process executes in its own application code and does not require kernel resources to compute, manage memory, or set variables

3.4 System Mode CPU Utilization

Shows the percentage of CPU time that is spent in system mode, including the CPU resources consumed by kernel processes (Kprocs) and other processes that require access to the kernel resources, the processes that the system uses for CPU include: For system calls, for I/O management (interrupts and drives), for memory management (paging and Swapping), used for process management (context switch and process start), if a process requires kernel resources, it must perform a system call and switch to system mode to make the resource available.

3.5%wa (Wait)

Shows the percentage of CPU idle for standby local disk I/O and NFS loaded disks, which is the rate at which the CPU is idle due to the process waiting for I/O, mainly including: Block I/o,raw i/o,vm-paging/swapins. If there is at least one outstanding disk I/O during the wait run, the event is classified as I/O wait time, the I/O request to the disk causes the calling process to block (or sleep) until the request is complete, and the process is placed in the run queue once the process's I/O request completes. If I/O is completed quickly, the process can use more CPU time.

3.6%id (Idle)

In addition to idle conditions above wio, the percentage of time that the CPU is idle or waiting is shown when there is no local disk I/O. If no thread can execute (the run queue is empty), the system assigns a thread called wait, which can be called an idle kproc. If the PS report shows that the total time for this thread is high, this indicates that there is a time period where no other threads are ready to run on the CPU or wait for execution. The system therefore spends most of its time idle or waiting for new tasks.

3.7 R (Runq-sz)

The length of the running process queue. These processes are ready in memory for the size of the number of processes that can run

4. Concept Introduction 4.1 user mode + kernel mode

In general, a process running on the CPU can have two modes of operation, both in user mode and in kernel mode (that is, the process is working in both the user and kernel states, and the kernel state is still the process, unless the process is switched on). Usually the operating system divides the virtual address space into user space and kernel space, for example, the Linux system virtual address space of the x86 platform is 0X00000000~0XFFFFFFFF, the first 3GB (0X00000000~0XBFFFFFFF) is the user space, The rear 1GB (0XC0000000~0XFFFFFFFF) is the kernel space. The user program loads into the user space, executes in user mode, cannot access the data in the kernel, and cannot jump to the kernel code to execute. This protects the kernel, and if a process accesses an illegal address, the process crashes at most, without compromising the stability of the kernel and the system as a whole. The CPU will not only jump to the break or exception service to the West, but also automatically switch mode from user mode to privileged mode, so from the interrupt or the exception server program can jump into the kernel code to execute. In fact, the entire kernel is made up of various interrupts and exception handlers. That is, under normal circumstances, the processor in user mode to execute the user program, in the event of an interruption or exception, the processor switches to privileged mode to execute the kernel program, after processing the interrupt or exception, and then return to user mode to continue to execute the user program, for example, user process a called the kernel system call to get the current clock tick number, When executing the system call instruction in user process A, the current register state such as Ip,cs of the current user process is saved, and then jumps to kernel space (that is, the kernel code region) to perform the system call function as expected to get the current number of clock ticks. After execution, the iret instruction is returned to process a (that is, the information saved at the time of entry is reset to the appropriate register), and then the instruction of a process is executed from the CS:EIP address.

In addition to creating the process's control block, the process creates the kernel stack of the process in the kernel, and the process enters the kernel through system calls (such as fopen () or open ()), when the processor is in the highest-privileged (level 0) kernel code, and when the process is in the kernel State, The kernel code that executes will use the kernel stack of the current process, which is directed to the context of the process,

Kernel-mode permissions are higher than user-mode permissions.

User-level. System users can interact with the operating system, such as running applications and system commands, at the user level through the system call interface, at the kernel level. The operating system automatically runs a number of functions that operate primarily on the hardware

4.2 Process Scheduling

Any process that wants to occupy the CPU and thus actually be in the execution state must be dispatched through the process. The process scheduling mechanism mainly involves the scheduling mode, timing and scheduling strategy.

1. Dispatch mode

The Linux kernel is basically a "preemptive priority" approach, that is, when the process runs in user mode, whether or not voluntarily, under certain conditions (such as time slices run out or waiting for I/O), the core can temporarily deprive its operation and dispatch other processes into operation. However, once the process has switched to kernel mode, it will not be subject to the above restrictions until the process is dispatched until it returns to user mode.

The scheduling strategy in Linux system basically inherits the UNIX priority-based scheduling. That is, the core calculates a priority for each process in the system, which reflects the eligibility of a process for CPU use, i.e. high priority processes are first run. The core picks up one of the highest priority processes from the process readiness queue and allocates a CPU time slice to run it. In the process of running, the priority of the current process decreases over time, thus achieving a "negative feedback" effect: After a period of time, the lower level of the original process is relatively "elevated" level, so that there is a chance to get run. When the priority of all processes becomes 0 o'clock, the priority of all processes is recalculated.

2. Scheduling policy

The Linux system provides three different scheduling strategies for different classes of processes, namely Sched_fifo, SCHED_RR, and Sched_other.

Sched_fifo is suitable for real-time processes, they are more time-dependent, and the time required for each run is relatively short, once the process has been scheduled to run, it will be running until the CPU is voluntarily released, or the higher priority process to preempt its execution.

The SCHED_RR corresponds to a "time slice rotation method", which is suitable for a real-time process that takes a long time each time it runs. A running process allocates a time slice (such as 200 milliseconds), when the time slice is exhausted, the CPU is preempted by another process, and the process is sent back to the end of the same priority queue. Sched_other is a traditional UNIX scheduling strategy, which is suitable for interactive time-sharing process. The priority of such a process depends on two factors, one of which is the quota for the remaining time of the process, the corresponding priority is 0 if the process has run out of allotted time, and the other is the priority of the process nice, which is a method inherited from a Unix system, with a lower priority and higher priority.

The value range for Nice is 19-20. You can use the Nice command to set the nice value of the process. However, the average user can only set positive values, thereby proactively reducing their priority; only privileged users can place nice's value negative. The priority of the process is the sum of the above. The core dynamically adjusts the priority of the user-state process. Thus, a process terminates after it has been created to complete a task and needs to undergo multiple feedback loops. When the process is scheduled to run again, it resumes execution from the last breakpoint. For a real-time process, the value of its priority is (1000+ set positive values), so at least 1000. Therefore, the priority of the real-time process is higher than other types of processes. In addition, time quotas and nice values are independent of the priority of the real-time process. If a real-time process in the system is in readiness, the non-real-time process cannot be scheduled to run until all real-time processes are complete and the non-real-time process has the opportunity to consume the CPU.

Background commands (with & symbols at the end of the command, such as GCC f1.c&) correspond to background processes (also known as background jobs), and background processes have a lower priority than any interaction (foreground) process. Therefore, the background process is scheduled to run only if there are no running interactive processes currently in the system. Background processes are often scheduled to run on a batch basis.

3. Scheduling time

The timing of the core process scheduling is as follows:

(1) The current process calls the system call Nanosleep () or pause () to put themselves into sleep, and actively let go for a period of time the CPU use;

(2) The process terminates and permanently abandons the use of the CPU;

(3) During the execution of the clock interrupt handler, it is found that the current process is running continuously for a long time;

(4) When a sleep process is awakened, the awakened process is found to be more qualified to run than the current process;

(5) A process that changes the scheduling policy or lowers its own priority (such as the Nice command) by executing a system call, causing immediate dispatch.

4. Scheduling algorithm

The algorithm for process scheduling should be relatively simple in order to reduce the overhead of frequent scheduling. When Linux executes a process schedule, it first finds all processes in the ready queue, from which a process with the highest priority and in memory is selected. If there are real-time processes in the queue, the real-time process will run first. If the process that most needs to run is not the current process, the current process is suspended and all the machine States involved in its field are saved, including program counters and CPU registers, and then the site is resumed for the selected process.

4.3 User-level threads vs. kernel-level threads

In many Unix-like systems, such as Linux, FreeBSD, Solaris, and so on, the process has always been the smallest unit of operating system kernel calls, and program development has also adopted a multi-process model. Threading concepts were later introduced with threads with the following two concepts:

User-level thread (User-level thread,ult). The application process uses the line libraries to create and manage, does not implement the thread in the kernel, only simulates the multi-threading in the user state, does not depend on the operating system core, the operating system kernel does not know the multi-threading existence completely.

Kernel thread threads (kernel-level thread,klt), also known as kernel-supported threads or lightweight processes. is implemented in the core space, the kernel sets up a thread control block in the core space for each thread to register the thread identifier, register value, state, priority, and so on, all operations on the thread, such as Create, undo, and toggle, are done by the appropriate handler in the kernel through the system function call. Kernel maintenance process and thread context switch and thread switching, UNIX-like systems are generally implemented by modifying the implementation of the process, you can use incomplete process creation method to create a shared data space process, under Linux This system call is Clone (), And under FreeBSD it is rfork ().

5. Common Misunderstanding 5.1 CPU utilization is high, CPU resources are not enough

When the CPU counters are not in range, it is not necessarily due to insufficient CPU resources, because other resources can also be caused, such as memory is not enough, the CPU will be busy memory management, the surface may be the utilization of the CPU for 100%

6. References

Http://blogread.cn/it/article/6522?f=hot1

http://blog.csdn.net/ouyangzhengxuan/article/details/7303562

http://bbs.csdn.net/topics/360197105

Http://blog.sina.com.cn/s/blog_43adf9fb0100a1t7.html

Http://blog.sina.com.cn/s/blog_5623cddb0100d15g.html

http://blog.csdn.net/yanglovefeng/article/details/7887939

Http://blog.163.com/[email protected]/blog/static/1122326372009116105156793/

http://oyqiaojin.blog.163.com/blog/static/5945256520132713448262/

Performance Analysis _linux Server CPU_CPU utilization