Profiling a Windows service for indefinite periods of time

Use this forum for questions on how to use .NET Memory Profiler and how to analyse memory usage.
Post Reply
pnschofield
Posts: 12
Joined: Thu Aug 02, 2007 7:42 pm

Profiling a Windows service for indefinite periods of time

Post by pnschofield » Thu Aug 02, 2007 7:49 pm

We need to profile a Windows service which may have an infrequent and currently unreproducible memory leak. The approach we'd like to take is to have a memory profiler running on the server, attaching to the service as it's starting up and then proceeding to log snapshots. It needs to be able to start up and attach to the service under any circumstances (e.g. after the machine has rebooted) to ensure it will be logging all the time.

Is this a scenario that's practical with .NET Memory Profile? Or is an alternate method suggested?

Would we have to write our own Windows service and use the Mem Profiler API to make this happen?

Paul Schofield
paul.schofield<at>broadlane<dot>com

pnschofield
Posts: 12
Joined: Thu Aug 02, 2007 7:42 pm

Post by pnschofield » Thu Aug 02, 2007 7:50 pm

Forgot to subscribe to thread on OP.

pnschofield
Posts: 12
Joined: Thu Aug 02, 2007 7:42 pm

Post by pnschofield » Thu Aug 02, 2007 8:25 pm

The service will allow me to write a plug-in component that can be loaded and executed, so I may end up writing some automation that way.

pnschofield
Posts: 12
Joined: Thu Aug 02, 2007 7:42 pm

Post by pnschofield » Thu Aug 02, 2007 9:00 pm

Of course, that would go into an infinite loop as the Mem Profiler restarts the service to attach, followed by the service starting an instance of Mem Profiler, ad infinitum.

Back to writing a separate service?

Paul

Andreas Suurkuusk
Posts: 1029
Joined: Wed Mar 02, 2005 7:53 pm

Post by Andreas Suurkuusk » Fri Aug 03, 2007 3:20 pm

It is possible to start profiling a process and collect snapshots automatically using command line parameters. Unfortunately, it is currently not possible to attach to a process using the command line, so the service must be started by the profiler. Unless you really need to attach, it is usually recommended that the profiled process is started from the profiler, as this will provide more detailed information.

The command line below will start the profiler and collect a snapshot every 10 minutes, which seems to be suitable for your purposes. If no user interface is wanted, the /noui parameter can be provided as well.

Code: Select all

<Installation path>\NetMemProfiler.exe /autocollect:10  /autosavesnapshot+ /service:<Service name>
For more information about the available command line parameters, see http://memprofiler.com/OnlineDocs/avail ... ptions.htm.

Instead of the /autocollect parameter, you can use the MemProfiler API to initiate snapshot collections from within the profiled process. However, this will not work if you attach to the process.
Best regards,

Andreas Suurkuusk
SciTech Software AB

pnschofield
Posts: 12
Joined: Thu Aug 02, 2007 7:42 pm

Post by pnschofield » Fri Aug 03, 2007 6:40 pm

Thank you for the command line. I can now launch the application from the command line. However, even with the addition of the /noui switch, it still launches the UI. I currently have the evaluation edition. Here's the full command line I'm using to launch the app:

Code: Select all

"C:\Program Files\SciTech\NetMemProfiler3\NetMemProfiler.exe" /autocollect:1  /autosavesnapshot+ /service:"IdeaBlade PersistenceServer Service" /noui

Andreas Suurkuusk
Posts: 1029
Joined: Wed Mar 02, 2005 7:53 pm

Post by Andreas Suurkuusk » Mon Aug 06, 2007 6:24 pm

The "/service" and "/program" arguments must be the last ones on the command line. The remainder of the command line is passed on to the profiled application (actually, in the current version no command line is passed to the service, but arguments after the service name are not parsed).

So to fix your problem, add the "/noui" switch before "/service", and things should work correctly.
Best regards,

Andreas Suurkuusk
SciTech Software AB

pnschofield
Posts: 12
Joined: Thu Aug 02, 2007 7:42 pm

Post by pnschofield » Mon Aug 06, 2007 8:24 pm

Never mind, I figured that out. So with that command line, is it saving the snapshots somewhere? I configured the /sessionfolder and /sessionfile parameters, but I can't tell whether or where it's saving anything.

Paul

Andreas Suurkuusk
Posts: 1029
Joined: Wed Mar 02, 2005 7:53 pm

Post by Andreas Suurkuusk » Tue Aug 07, 2007 9:10 pm

No session file is saved until the session is ended, e.g. when the service is stopped in your case. It is currently not possible to programmatically force the session file to be created while profiling or to end the session. To save the session while profiling you need to use the UI of the profiler (File->Save Session As...).

If you want the session file to be automatically saved when the session is ended, it is recommended that you provide the /sessionfile, /sessionprompt- and /autosavesnapshot options on the command line. This will make sure that the snapshots are saved in a session file, even if the default settings are different.

If you're running the professional edition, a better option is to define a project with all your settings and then start the profiler using the /project option.
Best regards,

Andreas Suurkuusk
SciTech Software AB

pnschofield
Posts: 12
Joined: Thu Aug 02, 2007 7:42 pm

Post by pnschofield » Tue Aug 07, 2007 9:21 pm

Where is all the session data stored prior to the file being written? Do I literally have to shut down a production Windows service in order to look at the logs?

Thanks,
Paul

Andreas Suurkuusk
Posts: 1029
Joined: Wed Mar 02, 2005 7:53 pm

Post by Andreas Suurkuusk » Wed Aug 08, 2007 3:19 pm

The temporary session file is stored in a temporary folder ("C:\Documents and Settings\<User>\Local Settings\Temp\MemProfiler").

When running the profiler without UI, it will exit when the profiled process is terminated. If you want to exit the profiler without stopping the service, you will need to terminate it using the Task manager (note that the service will continue to run with all profiler hooks and tracking enabled, which will affect the performance of the service). The temporary session file will then be available from the temporary folder. Additionally, the next time the profiler is started, you will get a prompt asking you how to handle the "left-over" session file.

In future version we will improve the possibilities to define how session files should be created while profiling, e.g. possibly by adding a SaveSession method in the profiler API. The possibility to make your own simple program or script to perform automated testing will also be included, probably in v3.2.
Best regards,

Andreas Suurkuusk
SciTech Software AB

pnschofield
Posts: 12
Joined: Thu Aug 02, 2007 7:42 pm

Post by pnschofield » Thu Aug 09, 2007 3:29 pm

Thank you for the information. How well does .NET Memory Profiler perform if I had it profile a service over a long period of time, say a week, and had it take a snapshot every hour or so on an application that was using approximately 1MB of memory? We think it may take a week or longer before we'll see our memory leak occur. I'm concerned that this may create a very large file that we'd have trouble analyzing in the MemProfiler application. Does the size of the session file ever become an issue?

Andreas Suurkuusk
Posts: 1029
Joined: Wed Mar 02, 2005 7:53 pm

Post by Andreas Suurkuusk » Fri Aug 10, 2007 4:09 pm

Collecting many snapshots mainly just makes the session file bigger, but there is one performance penalty. In order to reduce the size of the saved snapshots, only instances that differ between the snapshots are saved. So for instance when loading snapshot 5, the profiler might have to investigate snapshots 4, 3, 2 and 1 as well to find all instances. With a lot of snapshots, this might create a performance problem.
Best regards,

Andreas Suurkuusk
SciTech Software AB

Post Reply

Who is online

Users browsing this forum: Bing [Bot] and 19 guests