Once we have all the files on local machine you will see following screen after opening trace file with PerfView. I usually copy over trace file along with whole application directory to some local machine so I can analyze uninterrupted and off from production environment. After you complete trace session trace file will be written to the disk (tool will let you know exact location). Let it run for some time (I was collecting data for about 1 minute).
QUICK CPU USAGE LESSON INSTALL
> dotnet tool install -global dotnet-traceĪfter trace tool is installed we can start collecting sample data (recommended us to run this tool exactly when you have observed issues with the application): > dotnet-trace collect -p 4352 -providers Microsoft-DotNETCore-SampleProfiler Next step is to collect some data that we could use to analyze in more details what's going on and where to start to look for the issue root cause.įor this - we will need another global tool. Looking at counter data over the time - we saw that allocation rate increases, CPU usage increases, GC numbers go up.īut overall ~450MB allocation per second is not a good sign of healthy service (unless you expect it and the service is designed for that). This opens old school command prompt style diagnostics panel.Ĭounters are collected every second (set by refresh-interval argument) and values are displayed on the screen. > dotnet-counters monitor -refresh-interval 1 -p 4352 When found we can start counter monitor to see some of the indicators without collecting any process data yet. > dotnet tool install -global dotnet-countersįirst, we need to find applicable process ID for the gRPC service. What we can start with - collecting some traces from the running process. Which means that something is leaking somewhere and it leaks only under specific concrete conditions. Interesting fact here is that this behavior starts to appear only after running for a few days. We were expecting to see normal behavior and resource usage by the service - something like this over the time:īut, after few days of uptime - we were stuck with this picture from Task Manager: This time we had to deal with super high CPU usage by our gRPC service. Maintaining service with these constraints becomes frankly interesting and challenging. Here in our case - gRPC service has to run for days, weeks, maybe even months without any interruptions. Back in old days it was easy to set recycling options for IIS and all of the sudden your memory, CPU or any other issues are auto-magically gone. These kind of issues comes under the radar very easily when you are dealing with long-lived, high performant and heavily used service that is running for ages. We are back again in gRPC service and this time we will be working on another performance issue.