Visio Add-in for Operations Manager 2007 R2 BetaYesterday I was investigating runbooks consuming much memory. We had a number of runbooks running Powershell scripts and we could see that the Runbook server was almost out of memory. When looking in Task Manager we saw a lot of PolicyModule.exe processes, some using a lot of memory, but we had no mapping between running runbooks and running PolicyModule.exe process. We needed to figure out which script/runbook is consuming all the memory.
This can be done in a couple of different ways. One way is to publish Runbook Process ID for any activity in a runbook. To use Runbook Process ID you need to enable “Show common Published Data” in the Published Data dialog box. The published data will show you the PID for the PolicyModule.exe process.
Another way to get the PID is to look in the Orchestrator database. The following SQL query will show you runbook name, start and stop time and process ID.
SELECT POLICYINSTANCES.TimeStarted, POLICYINSTANCES.TimeEnded, POLICYINSTANCES.ProcessID, POLICYINSTANCES.SeqNumber, POLICIES.Name
FROM POLICYINSTANCES INNER JOIN POLICIES ON POLICYINSTANCES.PolicyID = POLICIES.UniqueID
ORDER BY POLICYINSTANCES.TimeStarted DESC
great Work, thanks for sharing!
But why does the powershell scripts take so much memory when they are run often?
Is it so that one must empty the powershell variables (which have a lot of data in memory) after using them in scripts?
I thought that when the script was finished running, it emptied all the powershell data out of the memory.
If not, I have to go through all my PS-scripts on the Orch-server and add this at the end of every one, ‘cos some of our PolicyModule.exe processes use more than 1.5GB memory..
Anders, I would like to point you to a tool I wrote, it’s called “Orchestrator Health Checker” which adds a lot of functionality to manage an Orchestrator Environment. That you describe here, it’s already covered in the tool. You can get the latest version from http://scorch.codeplex.com/releases/view/99063