From: Nilay Parikh Nilay on 5 Feb 2009 11:49 I am getting deadlock errors in content database during the performace test ramp up to 10 users. From the primary investigation, I found following possibility of the deadlock errors in content database. I have witnessed below warning logs in MOSS logs. 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: {70332369-F319-4431-9470-09243FFD40A0} 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. An SPRequest object was reclaimed by the garbage collector instead of being explicitly freed. 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. Allocation Id: {9F4F6EFE-15F2-4F64-9516-5E9E24497D43} 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. Potentially excessive number of SPRequest objects (9) currently unreleased on thread 7. Ensure that this object or its parent (such as an SPWeb or SPSite) is being properly disposed. This object is holding on to a separate native heap. Allocation Id for this object: {C544828A-B76E-446A-8B6C-B5209BF41066} 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_Req... 53 heaps created, above warning threshold of 32. Check for excessive SPWeb or SPSite usage. The frequncy of the above warning message is very high, and I feel due to no proper dispose method and close use the object is not relasing the lock and resultant sharepoint database procedures throws deadlock errors. Am I thinking on right direction, or there could be other possible reasons? Any input would be very appriciated. Kind Regards.
From: Bart Tubalinal on 5 Feb 2009 23:02 Yes, I think you're thinking in the right direction. Do you have custom code running on the site (like web parts, custom controls, event receivers, etc)? If so, then I would suggest using the recently released tool SPDisposeCheck which will analyze your assemblies and report on the lines where potential memory leaks might be occuring due to non-disposal of SPWeb and SPSite objects. The tool is available here: http://code.msdn.microsoft.com/SPDisposeCheck -- Bart X. Tubalinal www.deviantpoint.com "Nilay Parikh" <Nilay Parikh(a)discussions.microsoft.com> wrote in message news:6CAD7B43-A753-44CB-A835-24FF741AB795(a)microsoft.com... >I am getting deadlock errors in content database during the performace test > ramp up to 10 users. From the primary investigation, I found following > possibility of the deadlock errors in content database. > > I have witnessed below warning logs in MOSS logs. > > 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: {70332369-F319-4431-9470-09243FFD40A0} 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. > > An SPRequest object was reclaimed by the garbage collector instead of > being > explicitly freed. 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. > Allocation Id: {9F4F6EFE-15F2-4F64-9516-5E9E24497D43} 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. > > Potentially excessive number of SPRequest objects (9) currently unreleased > on thread 7. Ensure that this object or its parent (such as an SPWeb or > SPSite) is being properly disposed. This object is holding on to a > separate > native heap. Allocation Id for this object: > {C544828A-B76E-446A-8B6C-B5209BF41066} 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_Req... > 53 heaps created, above warning threshold of 32. Check for excessive SPWeb > or SPSite usage. > > The frequncy of the above warning message is very high, and I feel due to > no > proper dispose method and close use the object is not relasing the lock > and > resultant sharepoint database procedures throws deadlock errors. > > Am I thinking on right direction, or there could be other possible > reasons? > > Any input would be very appriciated. > > Kind Regards.
From: Nilay Parikh Nilay on 6 Feb 2009 08:41 Hi Bart, Thanks for sharing your views and suggestion, yes we are using lots of custom codes, also we have develop lot of custom workflow activity for portal workflows. I will check with the suggested tool. Kind Regards, Many Thanks, "Bart Tubalinal" wrote: > Yes, I think you're thinking in the right direction. Do you have custom code > running on the site (like web parts, custom controls, event receivers, etc)? > If so, then I would suggest using the recently released tool SPDisposeCheck > which will analyze your assemblies and report on the lines where potential > memory leaks might be occuring due to non-disposal of SPWeb and SPSite > objects. The tool is available here: > http://code.msdn.microsoft.com/SPDisposeCheck > > -- > Bart X. Tubalinal > www.deviantpoint.com > > "Nilay Parikh" <Nilay Parikh(a)discussions.microsoft.com> wrote in message > news:6CAD7B43-A753-44CB-A835-24FF741AB795(a)microsoft.com... > >I am getting deadlock errors in content database during the performace test > > ramp up to 10 users. From the primary investigation, I found following > > possibility of the deadlock errors in content database. > > > > I have witnessed below warning logs in MOSS logs. > > > > 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: {70332369-F319-4431-9470-09243FFD40A0} 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. > > > > An SPRequest object was reclaimed by the garbage collector instead of > > being > > explicitly freed. 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. > > Allocation Id: {9F4F6EFE-15F2-4F64-9516-5E9E24497D43} 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. > > > > Potentially excessive number of SPRequest objects (9) currently unreleased > > on thread 7. Ensure that this object or its parent (such as an SPWeb or > > SPSite) is being properly disposed. This object is holding on to a > > separate > > native heap. Allocation Id for this object: > > {C544828A-B76E-446A-8B6C-B5209BF41066} 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_Req... > > 53 heaps created, above warning threshold of 32. Check for excessive SPWeb > > or SPSite usage. > > > > The frequncy of the above warning message is very high, and I feel due to > > no > > proper dispose method and close use the object is not relasing the lock > > and > > resultant sharepoint database procedures throws deadlock errors. > > > > Am I thinking on right direction, or there could be other possible > > reasons? > > > > Any input would be very appriciated. > > > > Kind Regards. >
|
Pages: 1 Prev: Template codes Next: Had a problem during an inplace upgrade. Looking for advice. |