This article mainly explains the buffer tracking system call analysis, the main purpose is to explore and analyze the system call details of the CPU in the kernel or the part of the user space, and some problems can be found for performance or other problem research.
The first is two concepts:
-
Breakpoint tracking type, which interrupts the execution of the target program to obtain data when sampling, such as the strace command.
- Buffer tracking type, which is different from breakpoint tracking, it can cache the acquired detection data in the kernel, and the target program can be executed without interruption. The dtrace command is a buffer trace.
There are many system calls, and the Linux operating system may have hundreds of them (there is no specific statistics).
Case 1:
We take a system call kill related to inter-process communication as an example to detect specific conditions in the system. The command is as follows:
sudo dtrace -qn 'syscall::kill:entry { printf("%Y: %s (PID %d) sent a SIG %d to PID %d\n",walltimestamp,execname,pid,arg1,arg0);}'The execution result is as follows, where PID=1 bit init process, it is the ancestor process of all other user processes, and will monitor other processes.
Let's analyze the first line: the init process sends a SIG signal 15 to PID -13929, where SIG 15 refers to the SIGTERM signal
Case 2:
We can use the dtrace command to analyze the system call of the Postgres database process.
command:
sudo dtrace -n 'syscall:::entry /execname == "postgres"/ { @[probefunc] = count(); }'The execution results are as follows. Among them, you can see that the system calls lseek/read_nocancel. There are many calls, which are related to file operations. It can be guessed that the postgres database is processing more files at this moment. If you want to analyze in depth, you need to look at the current postgresql management. Other indicators of the system, such as actions being executed by the system, SQL, tasks, etc.
