Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

I am running sharepoint server 2010 with 8GB RAM. I have a SP Designer Workflow running on my portal. The server used to respond but now when users try to hit the URL they get an error message. I checked on my server only to realise that the OWStimer.exe takes much memory which explains why users get request time out error. I restarted the server but after 2-4 hrs its start running very slow and memory usages goes to 95%(7.95 GB). OWSTIMER.exe takes 6.6GB.

I read many articles and they think this might be happening due to the fact that I have a workflow running but the reality is that I also need that workflow for my document approval.

Your assistance will be much appreciated.

share|improve this question
1  
Is it a custom workflow using VS2010? Do you have custom timer jobs? –  David Lozzi Nov 14 '11 at 13:13
    
Hi David, I have a custom action for SharePoint Designer. I developed it using VS2010. Do you have any idea what might be the issue? –  Sepaka Nov 15 '11 at 6:06
    
Are you disposing your SPSite/SPWeb objects in code? The timer service actually runs the workflows, and if you have some leaky code, it'll flood your basement. –  David Lozzi Nov 15 '11 at 12:03
    
Not disposing it to code –  Sepaka Nov 16 '11 at 8:12
    
? are you instantiating new SPSite or SPWeb objects? –  David Lozzi Nov 16 '11 at 12:53
add comment

2 Answers

Make sure you've installed KB946517. OWSTIMER used to cause major memory leaks. We had a consultant recommend we set up a daily job to restart the timer service because of known memory leak issues. Apparently, this hotfix addresses this issue.

share|improve this answer
    
Thanks Ronx. Does this apply to SharePoint 2010 or is it only for wss? –  Sepaka Nov 28 '11 at 7:12
    
According to Todd Carter, only MOSS 2007 & WSS 3.0 are affected. The hotfix is for Server 2008, though, so it might be worth reviewing/applying just to make sure the root cause is eliminated. –  ronx Dec 14 '11 at 2:18
add comment

I have encountered this issue twice and both times it was workflow related. Completely deleting and then recreating the workflows solved the issue both times.

There is an issue that we documented with Microsoft where, under certain conditions, a workflow would duplicate some nodes in its XML thousands of times, resulting in a single workflow that was over 250MB in size, which then had to be parsed and processed every time the workflow loaded, resulting in massive memory consumption and high CPU usage. These appeared to be very simple workflows that did nothing that unusual.

Unfortunately, we were never able to determine exactly what the conditions were that causes this to happen.

share|improve this answer
    
Thanks Dave, It looks we have a long way to go. –  Sepaka Nov 15 '11 at 6:10
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.