Applications developed with Microsoft
technology use the .NET framework. This framework provides counters to measure
and monitor performance of the applications. The .NET Framework has two main
components:
·
The
common language runtime
·
The
.NET Framework class library
The common language runtime (CLR) is
the foundation of the .NET Framework. You can think of the runtime as an agent
that manages code at execution time, providing core services such as memory
management, thread management, and remoting, while also enforcing strict type
safety
and other forms of code accuracy that
promote security and robustness. In fact, the concept of code management is a
fundamental principle of the runtime. Code that targets the runtime is known as
managed code, while code that does not target the runtime is known as unmanaged
code. The
class library, the other main
component of the .NET Framework, is a comprehensive, object-oriented collection
of reusable types.
.NET performance counters are organized
into nine important categories:
·
Exceptions: Provides information about the exceptions
thrown by the application.
·
Memory: Provides information about the garbage
collector.
·
Locks and Threads: Provide information
about managed locks and threads used by the application.
·
Interop: Provides
information about the application’s interaction with COM components, COM+
services, and type libraries.
·
JIT: Provides information about code that has been
compiled by the justin-time (JIT) compiler.
·
Loading: Provides
information about assemblies, classes, and AppDomains that have been loaded.
·
Networking:
Provides information about the data sent and
received over the network by the application.
·
Remoting: Provides information about remote objects used
by the application.
·
Security: Gives a description about the security checks
the CLR performs on the application.
When monitoring .NET applications, it
is recommended to start monitoring from operating system counters that measure
the utilization of the processors, the memory, the network, and the I/O devices.
Then you can add .NET performance counters that cover every aspect of the CLR
operations ranging from exception processing to security checking.
Counter
|
Description
|
|
Exception
|
# of Excep Thrown/sec
|
Indicates the number of managed code exceptions thrown per second
|
Throw to Catch
Depth/Sec |
Indicates the number of stack frames
|
|
Memory
|
Large Object Heap Size
|
Indicates the current size of the Large Object
Heap in bytes |
# Bytes in all Heaps
|
Indicates the current memory allocated in bytes
on the GC heaps. |
|
# of Pinned Objects
|
Indicates the number of pinned objects
encountered in the last garbage collection (GC). |
|
% Time in GC
|
Indicates the percentage of elapsed time that was
spent in performing a garbage collection (GC) since the last GC cycle. |
|
Threads
|
# of Current Logical threads
|
Indicates the number of current .NET thread
objects in the application. |
# of Current Physical Threads
|
Indicates the number of native OS threads
created and owned by the CLR. |
|
# of Current Recognized Threads
|
Indicates the number of threads currently
recognized by the CLR. |
|
# of Total Recognized Threads
|
Indicates the total number of threads recognized
by the CLR since the start. |
|
Contention Rate/Sec
|
Indicates the rate at which threads in the
runtime attempt to acquire a managed lock unsuccessfully |
|
Loading
|
Current Assemblies
|
Indicates the number of assemblies that are
loaded in the process. |
Rate of Assemblies
|
Indicates the rate at which assemblies are loaded
into the memory per second. |
|
Bytes in Loader Heap
|
Indicates the number of bytes committed by the
class loader. |
|
Security
|
Total Runtime Checks
|
Indicates the percentage of elapsed time spent in
performing runtime Code Access Security. |
Stack Walk Depth
|
Indicates the depth of the stack during that last
runtime Code Access Security check. |
No comments:
Post a Comment