Brad Turner

I have a test Sequential Workflow that contains a DelayActivity which is configured for several minutes. After the workflows have been created and persisted, the console application hosting the workflow runs at or near 100% CPU usage until the timers fire and workflows reload and complete.

Is it normal for the workflow runtime (or is it the persistence service) to clock the CPU while it's doing nothing but waiting



Re: Windows Workflow Foundation SQLPersistenceService high CPU usage?

Darren Headrick - MSFT

I havent seen this behavior before, and I would hope that it isnt the expected behavior Smile Are you seeing this behavior with the default settings Are you using any custom settings like changing a load interval , etc If possible could you post the relevant code snippets from you main app




Re: Windows Workflow Foundation SQLPersistenceService high CPU usage?

Jerry Camel

Here's some code that exhibits the above described behavior...

It's a Workflow Console Application project. It seems that when the workflow and app are defined within the same project, this problem occurs. When they are created as separate projects within the same solution (i.e. Console app and Workflow Lib) then this doesn't happen.

Here's the code from the console app module:

Code Snippet

Module Module1

Class Program

Shared wfr As WorkflowRuntime

Shared sql As SqlWorkflowPersistenceService

Shared Sub Main()

Dim l As List(Of SqlPersistenceWorkflowInstanceDescription)

Dim t As Thread = New Thread(AddressOf InstantiateWorkflows)

t.Start()

t.Join()

Dim processing As Boolean = True

Do

Console.WriteLine("Checking for persisted workflows...")

l = CType(sql.GetAllWorkflows(), List(Of SqlPersistenceWorkflowInstanceDescription))

If l.Count < 1 Then

processing = False

Console.WriteLine("None Found.")

Else

Console.WriteLine("Found " & l.Count & " persisted workflows.")

Thread.Sleep(10000)

End If

Loop While processing

wfr.StopRuntime()

Console.WriteLine(vbCrLf & "-- Press Enter To Exit --")

Console.ReadLine()

End Sub

Shared Sub InstantiateWorkflows()

wfr = New WorkflowRuntime()

sql = New SqlWorkflowPersistenceService("Initial Catalog=SqlPersistenceService;Data Source=Camel\SQL2005;Integrated Security=SSPI;", False, New TimeSpan(0, 0, 10), New TimeSpan(0, 0, 10))

AddHandler wfr.WorkflowCompleted, AddressOf OnWorkflowCompleted

AddHandler wfr.WorkflowIdled, AddressOf OnWorkflowIdled

wfr.AddService(sql)

'wfr.StartRuntime() 'If you do this little dance of starting and stopping the workflow runtime before

'wfr.StopRuntime() 'adding any workflow instances, then the CPU utilization problem seems to go away!

'wfr.StartRuntime()

For i As Integer = 1 To 10

Dim wfi As WorkflowInstance

Dim parms As Dictionary(Of String, Object) = New Dictionary(Of String, Object)

parms.Add("WorkflowName", "Workflow " & i)

parms.Add("DelayDays", New TimeSpan(0, 0, 30))

wfi = wfr.CreateWorkflow(GetType(Workflow1), parms)

wfi.Start()

Thread.Sleep(500) 'This is just to space out the workflow creations.

Next i

End Sub

Shared Sub OnWorkflowCompleted(ByVal sender As Object, ByVal e As WorkflowCompletedEventArgs)

Console.WriteLine("Workflow completed: " & e.OutputParameters("WorkflowName").ToString())

End Sub

Shared Sub OnWorkflowIdled(ByVal sender As Object, ByVal e As WorkflowEventArgs)

e.WorkflowInstance.TryUnload()

End Sub

End Class

End Module

So why does this cause the CPU to spin at 90+ percent even when the workflows are persisted

And why does starting and stopping the runtime before hand cure this behavior

Thanks.

J






Re: Windows Workflow Foundation SQLPersistenceService high CPU usage?

Brad Turner

No takers on this - Jerry and I were able to confirm that the issue seems to be related to how the project is built and less to do with the actual code. We're just not sure why this would matter and it seems like a bug somewhere - I'm really surprised no one else has come across this.

At first I thought it was the fact that this was a console application, but further testing with a service and a windows form application both revealed the same behavior - if the workflow is added to an existing project the CPU clocks, but if a separate project is added to the solution it works fine.





Re: Windows Workflow Foundation SQLPersistenceService high CPU usage?

Darren Headrick - MSFT

I havent been able to reproduce this, could I get a copy of a sample workflow that is showing this behavior t-dheadr AT microsoft.com. Thanks.




Re: Windows Workflow Foundation SQLPersistenceService high CPU usage?

Darren Headrick - MSFT

I still havent been able to reproduce this problem, but I would like to make a few suggestions. Workflow will automatically unload worklfows when they go idle if you change the SQLPersistenceService constructor unloadOnIdle to true, so the tryunload in OnWorkflowIdled, is kind of uneccesary. Second I would discourage checking the count of the number of workflows in the database as your stop condition, Since you are catching the workflow completed (and you probably should catch the workflow terminated) you should know when workflows complete, and then you can just keep a count of how many have completed and stop after the number you started have completed. The current way this is implemented would never complete if you had say another workflow that was persisted waiting for youtrs to complete, a sitution which is quite common. Finally, what process do you see eating your cpu cycles Is it sql server, Visual stuido, etc Just out of curiosity what OSes are you seeing this behavior on




Re: Windows Workflow Foundation SQLPersistenceService high CPU usage?

Brad Turner

It's a Sequential Workflow with a single Delay activity.

Here are the steps to use when creating the solution from Visual Studio 2005:

  1. New Project/Workflow
  2. Sequential Workflow Console Application
  3. Add a Delay Activity to the workflow, set the delay for one minute
  4. Run the app - cpu clocks up to 100% for the application
We've repro'd this on two separate boxes - both XP Pro SP2, SQL 2005 w/SP2.





Re: Windows Workflow Foundation SQLPersistenceService high CPU usage?

Darren Headrick - MSFT

The workflow which you posted shouldnt even use the workflow persistence service, this seems more like an issue with the machines either not having enough power or having other processes in the background. Are you running this in visual studio If so have you tried running without the debugger




Re: Windows Workflow Foundation SQLPersistenceService high CPU usage?

rlrcstr

Darren,

In regards to your comments about the workflow count checking, etc. - this is just a little sample app to illustrate the CPU issue. This is not anything that would go into production and wasn't designed to handle any workflows other than this simple example. The purpose was just to have an app that creates a bunch of workflows and then waits while they persist, inflate and complete. Just to watch the CPU utilization NOT drop after all of the workflows are persisted. Once everything is persisted, we expected the CPU utilization to drop. (The anomaly is that it DOES drop if you do the start-stop-start dance before creating the workflows, or anytime, really. After that it behaves normally.)

As we pointed out, this seems to be specific to workflow apps that are wholly contained within a single project. If two separate projects are used, then this doesn't happen, even if the functionality is identical. For our production work, we're architecting the solution with multiple projects, etc, and we are not encountering this issue. We just wanted to put it out there because we did see it while working through some sample stuff just to get up to speed on the workflow foundation and figured someone should know about it.

The process that eats the CPU time is the application itself. Seems to be related to the WorkflowRuntime instance and the way the single project solution is built.

In addition to Brad's steps in how to recreate this, another way is as follows:

1) Create a standard console or WinForms app.

2) Edit the project file directly and add the <ProjectTypeGUIDs> element that you find in a template created workflow console app.

3) Start the project in VS and add the necessary Imports, etc. and create a basic workflow app out of it.

4) Run the app and note how the CPU utilization stays high even if all of the workflow runtimes are persisted.

When I was getting up to speed on this stuff, it was the only way I could see to create a WinForms workflow app that is a single project. The templates include a console WF app, but not one for WinForms.

Mostly this is an exercise in understanding how VS is creating these projects and trying to understand why the WorkflowRuntime behaves differently in the single project apps than it does in the multi-project apps.

If you can't recreate this, then perhaps it has something to do with a tear in the space/time contiuum and the location where we were testing...

Jerry






Re: Windows Workflow Foundation SQLPersistenceService high CPU usage?

Brad Turner

Right, in this case it's not using the persistence service, but the problem does not appear if you create two projects and add them to the same solution. This is debugging through VS, but it appears and disappears based on how the project/solution is built.

It's not the machines themselves as they run happily if you craft the solution differently.





Re: Windows Workflow Foundation SQLPersistenceService high CPU usage?

Brad Turner

The process consuming the CPU is the console application (while debugging). This is XP Pro SP2, Visual Studio 2005, SQL 2005 SP2.

Debugging the workflow split into two projects (a console project and a workflow library project in the same solution) does not exhibit this behavior.





Re: Windows Workflow Foundation SQLPersistenceService high CPU usage?

Darren Headrick - MSFT

What process is actually using the cpu %




Re: Windows Workflow Foundation SQLPersistenceService high CPU usage?

Brad Turner

The console application that is being debugged is the one consuming the CPU.

[Edit: However, we've also seen the same behavior on a Windows Service, and a WinForms app]





Re: Windows Workflow Foundation SQLPersistenceService high CPU usage?

Darren Headrick - MSFT

Have you tried running without the debugger Does it still show the same behvaior




Re: Windows Workflow Foundation SQLPersistenceService high CPU usage?

Brad Turner

I was just able to confirm that if I run the compiled app it acts fine but running under the debugger causes the CPU to spike. So, does this then become a Visual Studio 2005 problem

We can't be the only ones debugging workflow's...