The translation is temporarily closed for contributions due to maintenance, please come back later.
English Persian
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.
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 setting the event for the counter, a sample rate can also be specified:
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 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 you invoke [command]#operf# on a command line without setting the _range_ option, data will be collected for the children processes.
Where _jvmti_oprofile_ is a path to the OProfile agent. For 64-bit JVM, the path looks as follows:
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:
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.
With _command_ and _args_, you can define a specific command or application to be profiled, and also the input arguments that this command or application requires. Either _command_, [option]`--pid` or [option]`--system-wide` is required, but these cannot be used simultaneously.
With [command]#operf#, there is no initial setup needed. You can invoke [command]#operf# with command-line options to specify your profiling settings. After that, you can run the OProfile post-processing tools described in xref:OProfile.adoc#s1-oprofile-analyzing-data[Analyzing the Data]. See xref:OProfile.adoc#s1-using-operf[Using operf] for further information.
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".
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.
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.
Your kernel's Performance Events Subsystem does not support your processor type