Inside Job

Making systems faster is a core part of business. Optimizing resources in data centers can save energy, space, and costs, and, out in the real world, a faster start-up time can improve the user experience for an entertainment system in the living room or even a car in the driveway.

In complex systems with many components, performance problems can stem from many different causes. On the hardware side, the CPU, RAM, the bus load, the memory system (block I/O), or the network can contribute to performance issues. On the software side, the operating system, the execution environment of the programming language, libraries, or the application itself can create bottlenecks. The fact that these components also often influence each other makes things more difficult. Although the systems work without any problems on their own, their interaction leads to friction.

To identify the root cause in the interaction of all these components requires the observer to take a bird's eye view and also have detailed knowledge of all the components. Not many IT professionals combine these skills, thus making performance optimization an exciting but challenging activity.

Fortunately, several useful tools are available for monitoring performance issues, including well-known utilities such as ps, stat, top, htop, OProfile [1], SystemTap [2], and so on.

One of the most useful performance monitoring tools is perf [3], which has been part of the kernel since version 2.6.31. perf uses the kernel's performance counter subsystem and supports both profiling and tracing.

During profiling, Perf evaluates data from hardware registers that count specific hardware events. Thus, it generates statistics at certain times in order to gain an impression of the system. The accuracy depends on the frequency of measurement.

In tracing, however, perf logs certain events using trace points. These include software events such as context changes, but also hardware events such as executed instructions, cache requests, and so on. System messages are also included.

Admins and developers should keep in mind that tracing can have a major influence on the system. In general, you need to take into account that the measurements themselves can influence the measurement results.

Installation

The perf program is part of the Linux kernel and located in the tools/perf directory. As the output from make tools/help shows, you can install with make -C perf_install. You can also simply change the directory to /usr/src/<Linux_version>/tools/perf and execute make there.

Because certain perf functions depend on the Linux application binary interface (ABI), distributions often ship one package per kernel version. Under Ubuntu 18.10, the linux-tools-generic package always installs the appropriate perf version.

If you want meaningful output, you also need to install the debug symbols for the programs you wish to example – just as you would with a debugger. The debug symbols are usually stored in separate archives. The packages automatically generated on Debian and Ubuntu 18.10 have an extension of -dbgsym, and the manually generated packages have an extension of -dbg.

Workflow

perf supports more than two dozen subcommands. For an overview, type the command without any parameters or check out the perf wiki [4]. People who use perf usually start with perf list. This command displays the available events (Listing 1), which you can then count with perf stat. The record command writes data to the hard disk; report displays the data for searching. script supports further evaluation of the data at the end.

01 $ sudo perf list hardware
02
03 List of pre-defined events (to be used in -e):
04
05 branch-instructions OR branches [Hardware event]
06 branch-misses [Hardware event]
07 bus-cycles [Hardware event]
08 cache-misses [Hardware event]
09 [...]

Events

The Admin perf list command also gives an optional argument on request (refer to Listing 1). This argument may be the type of the event, for example hw or tracepoint, or a regular expression, as in Listing 2.

01 $ sudo perf list 'block:*'
02
03 List of pre-defined events (to be used in -e):
04
05 block:block_bio_backmerge [Tracepoint event]
06 block:block_bio_bounce [Tracepoint event]
07 block:block_bio_complete [Tracepoint event]
08 block:block_bio_frontmerge [Tracepoint event]
09 block:block_bio_queue [Tracepoint event]
10 [...]

Each end of line contains the event type in square brackets. In addition, you normally have to look into the source code to see the exact meaning of the event. You can use the --events or -e switch to state the events to be considered.