Periodically, the OProfile daemon, oprofiled, collects
the samples and writes them to the
/var/lib/oprofile/samples/ directory. Before
reading the data, make sure all data has been written to this directory
by executing the following command as root:
Each sample file name is based on the name of the executable. For
example, the samples for the default event on a Pentium III processor
for /bin/bash becomes:
\{root\}/bin/bash/\{dep\}/\{root\}/bin/bash/CPU_CLK_UNHALTED.100000 |
The following tools are available to profile the sample data once it has
been collected:
Use these tools, along with the binaries profiled, to generate reports
that can be further analyzed.
 | Warning |
|---|
| | The executable being profiled must be used with these tools to analyze
the data. If it must change after the data is collected, backup the
executable used to create the samples as well as the sample files.
|
Samples for each executable are written to a single sample file. Samples
from each dynamically linked library are also written to a single sample
file. While OProfile is running, if the executable being monitored changes
and a sample file for the executable exists, the existing sample file is
automatically deleted. Thus, if the existing sample file is needed, it
must be backed up, along with the executable used to create it before
replacing the executable with a new version. Refer to Section 41.4 Saving Data for details on how to backup the
sample file.
The opreport tool provides an overview of all the
executables being profiled.
The following is part of an example output:
Profiling through timer interrupt
TIMER:0|
samples| %|
------------------
25926 97.5212 no-vmlinux
359 1.3504 pi
65 0.2445 Xorg
62 0.2332 libvte.so.4.4.0
56 0.2106 libc-2.3.4.so
34 0.1279 libglib-2.0.so.0.400.7
19 0.0715 libXft.so.2.1.2
17 0.0639 bash
8 0.0301 ld-2.3.4.so
8 0.0301 libgdk-x11-2.0.so.0.400.13
6 0.0226 libgobject-2.0.so.0.400.7
5 0.0188 oprofiled
4 0.0150 libpthread-2.3.4.so
4 0.0150 libgtk-x11-2.0.so.0.400.13
3 0.0113 libXrender.so.1.2.2
3 0.0113 du
1 0.0038 libcrypto.so.0.9.7a
1 0.0038 libpam.so.0.77
1 0.0038 libtermcap.so.2.0.8
1 0.0038 libX11.so.6.2
1 0.0038 libgthread-2.0.so.0.400.7
1 0.0038 libwnck-1.so.4.9.0 |
Each executable is listed on its own line. The first column is the
number of samples recorded for the executable. The second column is
the percentage of samples relative to the total number of samples. The
third column is the name of the executable.
Refer to the opreport man page for a list of
available command line options, such as the -r option
used to sort the output from the executable with the smallest number of
samples to the one with the largest number of samples.
To retrieve more detailed profiled information about a specific
executable, use opreport:
opreport <mode> <executable> |
<executable> must be the full path to
the executable to be analyzed. <mode>
must be one of the following:
- -l
List sample data by symbols. For example, the following is
part of the output from running the command opreport -l
/lib/tls/libc-<version>.so:
samples % symbol name
12 21.4286 __gconv_transform_utf8_internal
5 8.9286 _int_malloc
4 7.1429 malloc
3 5.3571 __i686.get_pc_thunk.bx
3 5.3571 _dl_mcount_wrapper_check
3 5.3571 mbrtowc
3 5.3571 memcpy
2 3.5714 _int_realloc
2 3.5714 _nl_intern_locale_data
2 3.5714 free
2 3.5714 strcmp
1 1.7857 __ctype_get_mb_cur_max
1 1.7857 __unregister_atfork
1 1.7857 __write_nocancel
1 1.7857 _dl_addr
1 1.7857 _int_free
1 1.7857 _itoa_word
1 1.7857 calc_eclosure_iter
1 1.7857 fopen@@GLIBC_2.1
1 1.7857 getpid
1 1.7857 memmove
1 1.7857 msort_with_tmp
1 1.7857 strcpy
1 1.7857 strlen
1 1.7857 vfprintf
1 1.7857 write |
The first column is the starting virtual memory address
(vma). The second column is the number of samples for the
symbol. The third column is the percentage of samples for this
symbol relative to the overall samples for the executable, and
the fourth column is the symbol name.
To sort the output from the largest number of samples to the
smallest (reverse order), use -r in conjunction
with the -l option.
- -i <symbol-name>
List sample data specific to a symbol name. For example, the
following output is from the command opreport -l -i
__gconv_transform_utf8_internal
/lib/tls/libc-<version>.so:
samples % symbol name
12 100.000 __gconv_transform_utf8_internal |
The first line is a summary for the symbol/executable
combination.
The first column is the number of samples for the
memory symbol. The second column is the percentage of samples
for the memory address relative to the total number of samples
for the symbol. The third column is the symbol name.
- -d
List sample data by symbols with more detail than
-l. For example, the
following output is from the command opreport -l -d
__gconv_transform_utf8_internal
/lib/tls/libc-<version>.so:
vma samples % symbol name
00a98640 12 100.000 __gconv_transform_utf8_internal
00a98640 1 8.3333
00a9868c 2 16.6667
00a9869a 1 8.3333
00a986c1 1 8.3333
00a98720 1 8.3333
00a98749 1 8.3333
00a98753 1 8.3333
00a98789 1 8.3333
00a98864 1 8.3333
00a98869 1 8.3333
00a98b08 1 8.3333 |
The data is the same as the -l option except
that for each symbol, each virtual memory address used is
shown. For each virtual memory address, the number of samples
and percentage of samples relative to the number of samples for
the symbol is displayed.
- -x <symbol-name>
Exclude the comma-separated list of symbols from the output.
- session:<name>
Specify the full path to the session or a directory
relative to the /var/lib/oprofile/samples/
directory.
The opannotate tool tries to match the samples
for particular instructions to the corresponding lines in the source
code. The resulting files generated should have the samples for the
lines at the left. It also puts in a comment at the beginning of each
function listing the total samples for the function.
For this utility to work, the executable must be compiled with GCC's
-g option. By default, Red Hat Enterprise Linux packages are not
compiled with this option.
The general syntax for opannotate is as follows:
opannotate --search-dirs <src-dir> --source <executable> |
The directory containing the source code and the executable to be
analyzed must be specified. Refer to the
opannotate man page for a list of additional
command line options.
