English Spanish
Your kernel's Performance Events Subsystem does not support your processor type
You might want to use SystemTap when instrumenting specific places in code. Because SystemTap allows you to run the code instrumentation without having to stop and restart the instrumented code, it is particularly useful for instrumenting the kernel and daemons.
xref:OProfile.adoc#tab_event_specifications[Event Specifications] summarizes these options. The last three values are optional, if you omit them, they will be set to their default values. Note that certain events do require a unit mask.
With this option, you can specify a path to a vmlinux file that matches the running kernel. Kernel samples will be attributed to this binary, allowing post-processing tools to attribute samples to the appropriate kernel symbols. If this option is not specified, all kernel samples will be attributed to a pseudo binary named "no-vmlinux".
While using OProfile is suggested in cases of collecting data on where and why the processor spends time in a particular area of code, it is less usable when finding out why the processor stays idle.
While OProfile can be used by developers to analyze application performance, it can also be used by system administrators to perform system analysis. For example:
Where _jvmti_oprofile_ is a path to the OProfile agent. For 64-bit JVM, the path looks as follows:
When using legacy mode, the OProfile daemon, [command]#oprofiled#, periodically 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:
When the OProfile daemon writes the profile data to sample files, it can separate the kernel and library profile data into separate sample files. To configure how the daemon writes to sample files, execute the following command as root:
When setting the event for the counter, a sample rate can also be specified:
When running [command]#operf# [option]`--system-wide`, it is recommended that your current working directory is `/root` or a subdirectory of `/root` so that sample data files are not stored in locations accessible by regular users.
when attempting to use [command]#operf#, try profiling with [command]#opcontrol# to see if your processor type may be supported by OProfile's legacy mode.
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
* `/usr/share/doc/oprofile/oprofile.html` — [citetitle]_OProfile Manual_
Using opreport on a Single Executable
Using operf on Virtual Systems
Using log file /var/lib/oprofile/oprofiled.log Daemon started. Profiler running.
Using [command]#opreport#
Using [command]#opannotate#
Use xref:OProfile.adoc#tb-oprofile-processors[OProfile Processors and Counters] to determine the number of events that can be monitored simultaneously for your CPU type. If the processor does not have supported performance monitoring hardware, the `timer` is used as the processor type.