• English日本語한국어
  • Log inStart now

.NET Performance Metrics

New Relic's .NET Agent collects metrics from the .NET runtime about the performance of your application. These metrics can provide insight into how much CPU and memory an application consumes as well as how the performance of an application may be impacted by garbage collection and thread pool resource contention.

The full suite of .NET Performance Metrics is available .NET Agent versions 8.20 and higher.

You can see these metrics at one.newrelic.com > All capabilities > APM & services. Select an application and go to More views > Dotnet VMs.

You can also view these metrics by:

CPU metrics

The following CPU Metrics are collected:

  • CPU/User/Utilization

    The percentage of CPU that is consumed by this process.
  • CPU/User Time

    The amount of time the process has spent executing application code.

Memory metrics

The following Memory Metrics are collected:

  • Memory/Physical

    The amount of private (physical) memory, in MB, allocated to the process.
  • Memory/WorkingSet

    Amount of physical memory allocated to the process.

Garbage collection metrics

The .NET Garbage collector runs in the background and is responsible for identifying and reclaiming memory tied to objects that are no longer referenced by an application. The following metrics may be useful in identifying patterns of object allocation and potential over-allocation scenarios. This article further explains the fundamentals of garbage collection in .NET.

Tip

Garbage collection metrics are available for:

  • All versions of the .NET Framework
  • .NET Core 3.0 and above.

Important

For .NET Framework applications, the Windows User under which your application runs must have access to windows performance counter data. Usually this is accomplished by adding the user to "Performance Monitor Users" and "Performance Log Users" groups. Insufficient permissions will result in the agent not collecting garbage collection metrics.

Overall metrics

Additionally, the following Garbage collection metrics are collected:

  • GC/Handles

    The number of references to objects.
  • GC/Induced

    Normally, the runtime performs garbage collection automatically. This metric identifies the number of times that Garbage Collection was manually invoked by an explicit call to GC.Collect from within application code.
  • GC/PercentTimeInGC (.NET Framework only)
    The percentage of elapsed time that the .NET runtime has spent performing garbage collection since the last garbage collection cycle.

Generation - 0 heap

The following GC Gen0 metrics are collected:

  • GC/Gen0/Size

    The amount of memory (in MB) that is available to be allocated in Generation 0. This does not indicate the amount of memory that is being used by Generation 0, but the maximum available to be allocated.
  • GC/Gen0/Promoted

    The amount of memory (in MB) that has survived garbage collection and has been promoted from Gen0 to Gen1. Memory survives garbage collection when there is an active reference to it.
  • GC/Gen0/Collections

    The number of times Generation 0 Garbage Collection was executed by the garbage collector.

Generation - 1 heap

The following GC Gen1 metrics are collected:

  • GC/Gen1/Size

    The amount of memory (in MB) that is used in the Generation 1 heap. This differs from Gen0/Size which measure the maximum amount of memory available for the generation 0 heap.
  • GC/Gen1/Promoted

    The amount of memory (in MB) that has survived garbage collection and has been promoted from Gen1 to Gen2. Memory survives garbage collection when there is an active reference to it.
  • GC/Gen1/Collections

    The number of times Generation 1 Garbage Collection was executed by the garbage collector.

Generation - 2 heap

The following GC Gen2 metrics are collected:

  • GC/Gen2/Size

    The amount of memory (in MB) that is being used by the Gen2 Heap.
  • GC/Gen2/Survived (.NET Core Only)
    The amount of memory (in MB) that has survived garbage collection. Memory survives garbage collection when there is an active reference to it. Unlike Gen0 and Gen1, memory that survives garbage collection is not promoted.
  • GC/Gen2/Collections

    The number of times Generation 2 Garbage Collection was executed by the garbage collector.

Large object heap (LOH)

The following GC LOH metrics are collected:

  • GC/LOH/Size

    The amount of memory (in MB) that is being used by the Large Object Heap (LOH). In .NET Core, the Large Object Heap is sometimes referred to as Gen3.
  • GC/LOH/Survived (.NET Core Only) The amount of memory (in MB) that has survived garbage collection. Memory survives garbage collection when there is an active reference to it. Unlike Gen0 and Gen1, memory that survives garbage collection is not promoted.

Managed thread pool metrics

The .NET runtime manages a pool of threads. The following metrics provide visibility into the performance of an application in terms of the thread pool and may help identify areas of thread pool starvation. Thread pool starvation/contention occurs when there are not enough threads available to process the requests made by an application. The following article describes the various features of the managed thread pool. Please note that these metrics do not include information about threads that are not managed by the thread pool.

Worker threads

Worker threads are CPU-bound threads that are employed to perform work on behalf of a process.

  • Threadpool/Worker/Available

    Identifies the number of managed threads available to the process. Consistently low numbers indicate a potential starvation scenario.
  • Threadpool/Worker/InUse

    Identifies the number of worker threads that are currently in use by the process.

Completion threads

Completion threads, sometimes referred to as I/O threads, are employed to monitor the completion of I/O operations.

  • Threadpool/Completion/Available

    This metric identifies the number of threads that are currently available to the process. Consistently low numbers indicate a potential starvation scenario.
  • Threadpool/Completion/InUse

    This metric identifies the number of completion threads currently in use by the process.

Throughput

Throughput metrics measure how much work has been requested to be performed on a different thread, the amount of work that has been started, and how much work is waiting for a thread pool resource to become available.

  • Threadpool/Throughput/Requested

    Identifies the number of times that work has been requested to be run on a different thread pool managed thread.
  • Threadpool/Throughput/Started

    Identifies the number of work items requested to be run on a separate thread that have started execution.
  • Threadpool/Throughput/QueueLength

    Identifies the number of work items that have been requested, but are waiting to start. Numbers that consistently increase indicate a potential thread pool starvation situation. The following article describes how to modify the number of threads that are available to an application.
Copyright © 2024 New Relic Inc.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.