Êíèãà: Embedded Linux Primer: A Practical, Real-World Approach
13.4.2. strace Variations
13.4.2. strace Variations
The strace utility has many command line options. One of the more useful includes the capability to select a subset of system calls for tracing. For example, if you want to see only the network-related activity of a given process, issue the command as follows:
$ strace -e trace=network process_name
This produces a trace of all the network-related system calls, such as socket(), connect(), recvfrom(), and send(). This is a powerful way to view the network activity of a given program. Several other subsets are available. For example, you can view only the file- related activities of a program, with open(), close(), read(), write(), and so on. Additional subsets include process-related system calls, signal-related system calls, and IPC-related system calls.
It is worth noting that strace is capable of dealing with tracing programs that spawn additional processes. Invoking strace with the -f option instructs strace to follow child processes that are created using the fork() system call. Numerous possibilities exist with the strace command. The best way to become proficient with this powerful utility is to use it. Make it a point with this and all the tools we present to seek out and read the latest open-source documentation. In this case, man strace on most Linux hosts will produce enough material to keep you experimenting for an afternoon!
One very useful way to employ strace is using the -c option. This option produces a high-level profiling of your application. Using the -c option, strace accumulates statistics on each system call, how many times it was encountered, how many times errors were returned, and the time spent in each system call. Listing 13-6 is an example of running strace -c on the webs demo from the previous example.
Listing 13-6. Profiling Using strace
root@coyote$ strace -c ./webs
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- --------
29.80 0.034262 189 181 send
18.46 0.021226 1011 21 10 open
14.11 0.016221 130 125 read
11.87 0.013651 506 27 8 stat64
5.88 0.006762 193 35 select
5.28 0.006072 76 80 fcntl64
3.47 0.003994 65 61 time
2.79 0.003205 3205 1 execve
1.71 0.001970 90 22 3 recv
1.62 0.001868 85 22 close
1.61 0.001856 169 11 shutdown
1.38 0.001586 144 11 accept
0.41 0.000470 94 5 mmap2
0.26 0.000301 100 3 mprotect
0.24 0.000281 94 3 brk
0.17 0.000194 194 1 1 access
0.13 0.000150 150 1 lseek
0.12 0.000141 47 3 uname
0.11 0.000132 132 1 listen
0.11 0.000128 128 1 socket
0.09 0.000105 53 2 fstat64
0.08 0.000097 97 1 munmap
0.06 0.000064 64 1 getcwd
0.05 0.000063 63 1 bind
0.05 0.000054 54 1 setsockopt
0.04 0.000048 48 1 rt_sigaction
0.04 0.000046 46 1 gettimeofday
0.03 0.000038 38 1 getpid
------ ----------- ----------- --------- --------- -----------
100.00 0.114985 624 22 total
This is a very useful way to get a high-level view of where your application is consuming time and where errors are occurring. Some errors might be a normal part of your application's operation, but others might be consuming time that you hadn't intended. From Listing 13-6, we can see that the syscall with the longest duration was the execve(), which is the call that the shell used to spawn the application. As you can see, it was called only once. Another interesting observation is that the send() system call was the most frequently used syscall. This makes sensethe application is a small web server.
Bear in mind that, like the other tools we have been discussing here, strace must be compiled for your target architecture. strace is executed on your target board, not your development host. You must use a version that is compatible with your architecture. If you purchase a commercial embedded Linux distribution, you should make sure that this utility is included for your chosen architecture.
Îãëàâëåíèå êíèãè
