- System requirements
- Profiler architecture
- Running the profiler
- Profiler activation
- Start profiling
- IDE integration
- Profile .NET executable
- Profile ASP.NET application IIS
- Profile all .NET processes that will start
- Attach profiler to a running application
- Profile remote applications
- Profiling in Docker container
- Manually enable profiling of local applications
- Startup options
- Profiling overhead: how to reduce or avoid
- Profiling troubleshooting
- Connect to profiled application
- Capturing snapshots
- Solving performance problems
- CPU profiling
- Threads
- Memory profiling
- Garbage collection
- Exception profiling
- Probes: monitor higher level events
- Performance Charts
- Inspections: automatic recognition of typical problems
- Automatically trigger actions on event
- Summary, snapshot annotation, automatic deobfuscation
- Time measurement (CPU time, wall time)
- Filters
- Snapshot directory customization
- Export of profiling results to HTML, CSV, XML, plain text
- Profiler API
- Profiler HTTP API
- Command line tool to control profiling
- Settings
Profiling troubleshooting
- Cannot profile a local application?
- Cannot profile a remote application?
- Check agent status in a web browser
- Enable extended diagnostics in the profiler UI log file
Cannot profile a local application?
-
Ensure that the application is started with the profiler and is running when you connect.
You cannot profile application started without the profiler. The only exception is applications running on .NET Framework 4 or newer, which support attaching of the profiler to an already running process. However, the attach mode has its limitations, thus you may prefer to start application with the profiler instead.
If the application has not started or unexpectedly terminated, check the application's output and logs for possible errors. Please also check the profiler agent log file
<user home>/.ynp/log/<session name>-<PID>.log
-
If the application is up and running, ensure that the profiler agent port is not blocked by a firewall, an antivirus etc. Check both the remote machine side and the local machine side. The profiler agent port must be allowed.
Please note, that agent port is not one of the ports you may use to communicate with the profiled application or server, like HTTP 8080. Instead, it's a special dedicated port used solely by the profiler.
By default, the profiler agent port is allocated in the range
10001-10010
or a random one is used if all ports in this range are busy. The port can also be specified explicitly with the startup optionport
. If the profiler agent port is not in the default range10001-10010
, explicitly specify the port in the connect dialog ashost:port
.If you are unsure which port is used, look at the profiler agent log on the remote machine. The profiler agent log file is
<user home>/.ynp/log/<session name>-<PID>.log
, where<user home>
corresponds to the account under which the profiled application is started.If you are uncertain about the log file path, you may find it in the profiler agent's output to stderr:
[YourKit .NET Profiler 2021.11-b123] Log file: <full path to the log file>
-
Due to some system settings such as security permissions, enabling profiling may not work for some .NET applications.
In this case, the application will start, but the profiler agent log file
<user home>/.ynp/log/<session name>-<PID>.log
will not be created.As a workaround, try to enable profiling manually.
-
If application to be profiled has started with the profiler, which is shown by the profiler agent log file which has been created (
<user home>/.ynp/log/<session name>-<PID>.log
), but the Welcome screen does not show the application, please try Profile remote application... action on Welcome screen, specifying "localhost" as host name, and using the port which you should have seen in the profiler agent log.
Cannot profile a remote application?
-
Ensure that the application is started with the profiler and is running when you connect.
If it didn't start or terminated by the moment, check the application's output, logs etc. for possible errors, or restart the application if it was intentionally shut down.
-
If the application is up and running, ensure that the network connection is not blocked by a firewall, an antivirus etc.
Check both the remote machine side and the local machine side.
The profiler agent port must be allowed.
The profiler agent port is not the same port as the ports which your profiled application normally uses, such as 8080 etc.
The default profiler agent port range is 10001-10010. When an application starts with the profiler, the profiler first makes attempt to allocate a free port in this range. Remote profiled applications listening on ports in this range can be automatically detected when you connect.
If all ports in the range are busy, an arbitrary port is chosen. In this case, you should explicitly specify the host and the port in the connect dialog as
host:port
You can find the port number on the remote machine in the log file<user home>/.ynp/log/<session name>-<PID>.log
Check agent status in a web browser
If the profiled .NET application is missing in Monitor Applications list,
then the profiler agent status can be checked by opening
the URL https://localhost:<agent port>
for a local profiled application
or https://<remote host>:<agent port>
for a remote profiled application
in a web browser.
The remote application status can be checked this way
if a direct connection was allowed with the help of the agent startup option
listen
.
If profiler agent uses self-signed SSL certificate (the default option), then all modern web browsers like Chrome, FireFox or InternetExplorer will show a security warning, explaining the risks. You can safely accept the risks and proceed further.
On the opened page you should see the version of the profiler agent you have connected to. Something like:
YourKit .NET Profiler 2021.11-b123
Enable extended diagnostics in the profiler UI log file
To help YourKit support investigate a network connectivity issue,
please enable extended log messages in the profiler UI log file by
adding the following line to <user home>/.ynp/ui.ini
:
-Dyk.ssh.debug=true