All aspects of user mode process management

5. System load average, use stress, mpstat, pidstat tools to find out the root cause of the increase in average load, 3 points, 1 point will be deducted for one missing screenshot, and 1 point will be deducted for one missing piece of advice

(1) System load average

The Load indicator indicates how many running tasks the system has within a specific time interval. Include:
①The number of tasks running on the CPU (running status)
②The number of tasks waiting for CPU scheduling (uninterruptible state)
③The number of tasks waiting for IO execution results (uninterruptible state)

? According to engineering experience, generally speaking, when the load indicator value of the system is greater than 1.5~2 times of the total number of CPU cores in the system, it indicates that the system load is heavy, and the reasons need to be analyzed and measures to reduce the load Index value. Otherwise, system lag may occur. If the system’s Load indicator value is greater than 3 times the total number of CPU cores in the system, it indicates that the system load is very serious.
? Note: If hyper-threading technology is supported, the total number of CPU cores here will be replaced by the total number of logical CPUs

(2) Tool description:

1. stress

? stress is a Linux system stress testing tool that can perform stress testing on CPU, Memory, IO, and disk. Here we use it as an abnormal process to simulate the scenario where the average load increases.

2. mpstat

? mpstat can view the average load of all CPUs, or the load of a specified CPU. So mpstat is actually a tool that mainly checks the CPU load. It is a commonly used multi-core CPU performance analysis tool, used to query the performance indicators of each CPU in real time, as well as the average indicators of all CPUs.

? Syntax: mpstat [options] [

? Options: [ -P { | ON | ALL } ]

? Interval: the interval between each report (seconds)

? Count: The number of times the report is displayed

3.pidstat

? pidstat is a commonly used process performance analysis tool, used to view the CPU, memory, IO, context switching and other performance indicators of the process in real time.

? Syntax: pidstat [options] [

(3) Experiment

? The way stress consumes CPU resources is by calling the sqrt function to calculate the square root of the random number generated by the rand function. Executing the command stress -c 4 will generate 4 such processes to continuously perform calculations:

? Execute the command mpstat -P ALL 1

? %usr represents the percentage of CPU used by the user

? %sys represents the percentage of CPU used by the kernel process

? From the picture above, we can see that the CPU is almost always running in user mode, and the running time is close to 99%. We can only see that the CPU may be severely loaded, but we cannot see the detailed average load of the system, so I executed top command:

? Only then did I discover that the CPU was severely loaded at this time. So I executed the command pidstat -u 1 to find out the severe load on the CPU:

? As can be seen from the above figure, the CPU is running these four stress processes almost all the time. It can be seen that the high load of the system at this time is caused by these four stress processes.

(4) Experience

? ①After studying this question, I have a systematic understanding of stress, mpstat, and pidstat tools, and I am now able to use them skillfully.

? ②Through the above experiments, I found that the high average load may be caused by CPU-intensive processes.

? ③When a high load situation occurs due to a CPU-intensive process, we can use the top command to check the load situation at this time, and then use the pidstat command to find the process that caused the high load situation, and then solve it.

6. Refer to the code on page P81 and write a program. The parent process prints the control menu and accepts commands (at least 5 commands listed above), then creates a child process and lets the child process handle the task while the parent process continues. Print menu and accept commands. Explain the debugging process and new experiences, and give screenshots. One point will be deducted for one missing command, and one point will be deducted for one missing piece of experience

(1) Procedure

menu.c code:

#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <string.h>
int main(int argc, char * argv[]) {
pid_t pid;
char cmd;
char * arg_psa[] = {"ps","-a",NULL};
char * arg_psx[] = {"ps","-x",NULL};
char * arg_stress[] = {"stress","-c","4","-t","100",NULL};
char * arg_uptime[] = {"uptime",NULL};
char * arg_pidstat[] = {"pidstat","-u","1","3",NULL};
while(1) {
printf("--------------------------------\
");
printf("input a run 'ps -a' commend\
");
printf("input x run 'ps -x' commend\
");
printf("input s run 'stress -c 4 -t 100' commend\
");
printf("input u run 'uptime' commend\
");
printf("input p run 'pidstat -u 1 3' commend\
");
printf("input q exit\
");
cmd = getchar(); //Accept input characters
getchar();
if((pid = fork()) < 0) { //Create child process
perror("fork error:");
return -1;
}
if(pid == 0) { //Subprocess
switch(cmd) {
case 'a':
execve("/bin/ps",arg_psa,NULL);
break;
case 'x':
execve("/bin/ps",arg_psx,NULL);
break;
case 's':
execve("/usr/bin/stress",arg_stress,NULL);
break;
case 'u':
execve("/usr/bin/uptime",arg_uptime,NULL);
break;
case 'p':
execve("/usr/bin/pidstat",arg_pidstat,NULL);
break;
case 'q':
break;
default:
perror("wrong cmd:\
");
break;
}
exit(0);
} else if(pid > 0) { //parent process
if(cmd == 'q')
break;
}
}
while(waitpid(-1,NULL,WNOHANG)>0);
return 0;
}

operation result:

To debug:

? Enter a to display all processes in a terminal:

? Enter x to display processes that do not control the terminal, and also display the specific paths of each command:

? Enter s to simulate a scenario where the average load increases:

? Enter u to view the average load at this time:

? Enter p to view the CPU usage of each process:

? Through the above running results, we know that this program can be used to simulate the experiment in question 5.

(2) Experience

? ① Personally, I feel that this program actually simulates a terminal, where we can implement input and output and add functions by ourselves.

? ② It gave me a more vivid understanding of the fork system call