Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

re: Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

Stefan Goßner — Tue, 20 Jul 2010 08:43:24 GMT

Hi Ali,

not every memory leak is related to SPWeb or SPSite. A detailed analysis of the memory pattern might be required to track this down. Also ensure to be on the latest SharePoint patch level to ensure that you are not running into an already fixed problem in the product.

Cheers,

Stefan

re: Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

Ali — Mon, 19 Jul 2010 16:44:06 GMT

Thanks for your reply Stefan. The settings did take place as per your suggestion but I am not able to remove the memory leaks error, not sure what is causing it as all my codes are properly disposing SPSite and SPWeb objetcs. Is there anything you think I should see ti improve the memory leakage errors. Also I increased the threshold to 150 in the registry key as per your recommendation to play with the threshold, but still no resolute.

Thanks.

re: Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

Stefan Goßner — Mon, 19 Jul 2010 08:56:31 GMT

Hi Ali,

after creating the key you need to do an IISRESET or restart the application pool to ensure that the setting takes effect.

Cheers,

Stefan

re: Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

Ali — Thu, 15 Jul 2010 22:38:50 GMT

Hi All,

I have a local intranet site that has approximately 2000 users. We have a custom web part deployed at the homepage of our site and people have complained that the web part disappears sometimes, it can be brought back by refreshing the page. The web part has caching enabled and we tested it at our Dev and QA servers and can not reproduce the same error.

I checked the ULS logs of our production enviornment and see the following errors with high priority:

An SPRequest object was not disposed before the end of this thread. To avoid wasting system resources, dispose of this object or its parent (such as an SPSite or SPWeb) as soon as you are done using it. This object will now be disposed. Allocation Id: {31C1D221-691D-4D95-839E-CFE855F7B114} To determine where this object was allocated, create a registry key at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\HeapSettings. Then create a new DWORD named SPRequestStackTrace with the value 1 under this key.

I tried creating a key as per their suggestion thinking I would be pinpointed to the appropriate DLL/Method. That was not very helpful.

I tried using Microsft SharePoint Memory Dispose Checker and thought it would resolve my problem and found 2 methods (not the same web part with caching) in my solution not disposing memory as per the best practices. I fixed them both and the results slighly improvised. I googled your blog and increased the threshold value of SPRequests. That again did thin down the errors, however I still have some errors coming up. My first guess to my web part caching problem would be to remove all these errors as that may burden the server.

I am sure there are no other codes that are not disposing memory as per the best practise. What am I missing? Why am I not able to reproduce the same web part error on my Dev and QA boxes? Why am I still getting the errors in my ULS Logs??

Thoughts??

re: Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

Stefan Goßner — Tue, 08 Dec 2009 12:27:49 GMT

Hi Jane,

it does not matter if this is in C#, VB.NET or powershell.

You always have to dispose these objects.

Cheers,

Stefan

re: Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

Jane Barrister — Tue, 08 Dec 2009 12:23:32 GMT

How does this apply to SharePoint 2010 and PowerShell with objects like SPSite, SPWeb, etc. Are there any best practices as to use this objecct and loop through them in PowerShell?

re: Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

Stefan Goßner — Fri, 13 Nov 2009 10:35:05 GMT

Hi Subhasis,

this is expected and by design. During crawl the same happens as if you would browse to the website. Except that crawl puts a pretty high load on the site. Every single instantiated SPWeb objects maintains its own SQL connection. As the crawler uses multiple threads to crawl the site it is like a load test against your site. All the navigation controls on the pages will get instantiated and will instantiate SPWeb objects.

So the only way to reduce the number of SQL connections would be to reduce the number of threads the crawler is using.

Cheers,

Stefan

re: Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

Subhasis — Fri, 13 Nov 2009 10:20:02 GMT

I have a strange error here.I have a content source. Whenever crawl runs,SQL connections goes too high. and only thing i got in the ULS logs is below

Potentially excessive number of SPRequest objects (12) currently unreleased on thread 9. Ensure that this object or its parent (such as an SPWeb or SPSite) is being properly disposed. Allocation Id for this object: {329BFC8D-6CB9-4C18-8048-72166ABE4E08} Stack trace of current allocation: at Microsoft.SharePoint.SPRequestManager.Add(SPRequest request, Boolean shareable) at Microsoft.SharePoint.SPGlobal.CreateSPRequestAndSetIdentity(Boolean bNotGlobalAdminCode, String strUrl, Boolean bNotAddToContext, Byte[] UserToken, String userName, Boolean bIgnoreTokenTimeout, Boolean bAsAnonymous) at Microsoft.SharePoint.SPWeb.InitializeSPRequest() at Microsoft.SharePoint.SPWeb.EnsureSPRequest() at Microsoft.SharePoint.SPWeb.get_Request() at Microsoft.SharePoint.SPWeb.SetMondoPr...

...ocHint(Int32 hint) at Microsoft.SharePoint.SPSite.OpenWeb(Guid gWebId, Int32 mondoHint) at Microsoft.SharePoint.SoapServer.CWebChange.CheckDB() at Microsoft.SharePoint.SoapServer.CWebChange..ctor(CChange parentChange, String strID, Boolean fDeleteEvent) at Microsoft.SharePoint.SoapServer.CSiteChange.GetWeb(String strID, Boolean fDeleteEvent) at Microsoft.SharePoint.SoapServer.SiteDataImpl.ProcessChanges(CChange change, SPChangeCollection spChangeCollection, SPChangeToken& spLastChangeToken, Int64& lTimeLeft) at Microsoft.SharePoint.SoapServer.SiteDataImpl.GetChanges(CChange change, SPChangeToken& spChangeToken_Start, SPChangeToken spChangeToken_End, Int64 lTimeout) at Microsoft.SharePoint.SoapServer.SiteDataImpl.GetChanges(ObjectType objectType, String contentDa...

1...tabaseId, String& startChangeId, String& endChangeId, Int32 Timeout, Boolean& moreChanges) at Microsoft.SharePoint.SoapServer.SiteData.GetChanges(ObjectType objectType, String contentDatabaseId, String& LastChangeId, String& CurrentChangeId, Int32 Timeout, Boolean& moreChanges) at System.RuntimeMethodHandle._InvokeMethodFast(Object target, Object[] arguments, SignatureStruct& sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner) at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean skipVisibilityChecks) at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture) at System.Web.Services... Windows SharePoint Services General 0 Medium ....Protocols.LogicalMethodInfo.Invoke(Object target, Object[] values) at System.Web.Services.Protocols.WebServiceHandler.Invoke() at System.Web.Services.Protocols.WebServiceHandler.CoreProcessRequest() at System.Web.Services.Protocols.SyncSessionlessHandler.ProcessRequest(HttpContext context) at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) at System.Web.HttpApplication.ApplicationStepManager.ResumeSteps(Exception error) at System.Web.HttpApplication.System.Web.IHttpAsyncHandler.BeginProcessRequest(HttpContext context, AsyncCallback cb, Object extraData) at System.Web.HttpRuntime.ProcessRequestInternal(HttpWo...

...rkerRequest wr) at System.Web.HttpRuntime.ProcessRequestNoDemand(HttpWorkerRequest wr)

Looks like the same error. But it happnes with crawl ? Any pointers. we have custom webparts. But RendertoIndexer property is already set to false. So webparts are not loaded during crawl. So what might be the reason of such high number of SP Requests ?

re: Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

Stefan Goßner — Thu, 05 Nov 2009 08:21:50 GMT

Hi Cornelius,

I have never seen this.

But the error indicates that you entered the registry value with the incorrect type. Did you use DWORD or string?

It should be a DWORD.

Cheers,

Stefan

re: Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007

Cornelius J. van Dyk — Wed, 04 Nov 2009 19:31:30 GMT

Hey Stefan,

We implemented your recommended changed on our QA SharePoint WFE server and then the WFE started throwing the following error for some unknown reason:

Server Error in '/' Application.

--------------------------------------------------------------------------------

Specified cast is not valid.

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.InvalidCastException: Specified cast is not valid.

Source Error:

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

Stack Trace:

[InvalidCastException: Specified cast is not valid.]

Microsoft.SharePoint.SPRequestManager.get_SPRequestsPerThreadWarning() +588

Microsoft.SharePoint.SPRequestManager.Add(SPRequest request, Boolean shareable) +695

Microsoft.SharePoint.SPGlobal.CreateSPRequestAndSetIdentity(Boolean bNotGlobalAdminCode, String strUrl, Boolean bNotAddToContext, Byte[] UserToken, String userName, Boolean bIgnoreTokenTimeout, Boolean bAsAnonymous) +2626

Microsoft.SharePoint.SPRequestManager.GetContextRequest(SPRequestAuthenticationMode authenticationMode) +192

Microsoft.SharePoint.Administration.SPFarm.get_RequestNoAuth() +25

Microsoft.SharePoint.ApplicationRuntime.SPHttpHandler.get_Hash() +162

Microsoft.SharePoint.ApplicationRuntime.SPHttpHandler.get_AppDomainIdHeader() +152

Microsoft.SharePoint.ApplicationRuntime.SPHttpHandler.OverrideExecuteUrlPath() +507

System.Web.DefaultHttpHandler.BeginProcessRequest(HttpContext context, AsyncCallback callback, Object state) +83

System.Web.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +8677954

System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +155

--------------------------------------------------------------------------------

Version Information: Microsoft .NET Framework Version:2.0.50727.3603; ASP.NET Version:2.0.50727.3082

The only way to get the WFE back online was to removed the registry entries and restart the services.

Researching the particular error yielded nothing except one Google cached paged that had the same problem on 9/29/09.

Do you have any ideas what might have caused the server to behave like that? (I'm not expecting you to miraculously know or be able to resolve the problem, but I'm hoping you might have seen a server do that before when applying these entries)

Thanks