2

There is an application that consists of three executable files. One of them - a dispatcher, which runs other executables. The dispatcher receives a code from an executable at its completion. That is, only the dispatcher is always running, other executables unloads and loads again. The application runs on the point of service and work around the clock. At the first launch the application works fast. At the end of the day, the application works terribly slow. What could be the reason for such a behavior?

EngineerSpock
  • 2,575
  • 4
  • 35
  • 57
  • Subscribing the same event repeatedly would do that. This is just a guessing exercise as long as you don't use a debugger. – Hans Passant Feb 25 '12 at 13:45

2 Answers2

7

There could be lot of reasons for a slow down over time. Anywhere from a slow memory leak to anti-virus. The best you can do is try to build evidence (data) about what area of the application to look first. Try not to talk it over with many devs because everyone will have a different opinion about what might be wrong. Get the data!

How to get the data:

perfmon perfmon is your friend. There are a lot of counters that you can look at (system wide as well as process specific). So you can start by profiling the big 4 (that's memory, disk usage, cpu and networking). There are a lot of posts out there about what counters are best, so I won't go into too much detail about the perf counters here.

windbg If you indeed see that memory is growing and not being collected it's time to bring in the big guns. .NET is great at abstracting memory usage away from developers, but this means we have to get underneath .NET sometimes to find out what is not allowing the Garbage Collector to do its work. windbg with the sos.dll (managed extensions) is a great tool for this. The hardest part of windbg (in my experience) is just getting the sos extensions loaded properly. You have to pay close attention to what target architecture (64 or 32) you are analysing and what CLR version you are running on.

procdump procdump by sysinternals is a great little utility to take memory snapshots from a running process. These snapshots (.dmp files) can then be analyzed by windbg.

sos The sos.dll has shipped with the .NET Framework since v2. With v4, Visual Studio 2010 has integrated sos and allows you to analyze .dmp files!

The sos commands for memory leaks that I have found most useful are:

!eeheap -gc (overview of what is in each generation of each heap)

!dumpheap -min <size> (dumps out all objects and types, over a particular <size>)

!dumpheap -type <type> (dump out all objects of a specific <type>)

!gcroot <address> (prints out a stack so you can see what parent object is pinning in the GC)

!do <address> (prints out memory of a specific object)

Some other pointers:

Usually, you want to snapshot memory under load, so it would be good to have some way to simulate that from outside the system. So, it is good to get this running ahead of time and even work it into the QA process for the application.

For performance problems it is usually best to take regular snapshots over time with a running application. Then you can compare the snapshots when you analyse.

Well, that was a bit longer than I intended, but hopefully worth it!

Davin Tryon
  • 66,517
  • 15
  • 143
  • 132
  • Awesome answer. I'll add that my first tool of choice is simply configuring task manager and watching the dynamics of resource allocation. – kenny Feb 25 '12 at 14:40
  • But how can it be that resources are not freed if exe is terminated? EXEs terminate itself by Application.Exit(int).The dispatcher is just a topmost window. There is no something that could lead to memory leaks (I guess). – EngineerSpock Feb 26 '12 at 14:31
  • @EngineerSpock Then, first measure system-level resources (CPU, Memory, Disk and Network). Next, find out which process is causing a spike in one of these. Refine your search and start again. It does take time, but be persistent and you'll find the cause. – Davin Tryon Feb 26 '12 at 16:41
1

You have to check the memory usage of your dispatcher application... it seems you are not disposing of unused objects.

Brian Mains
  • 50,520
  • 35
  • 148
  • 257
Mohammad Shraim
  • 1,173
  • 12
  • 21