Recently I had another service request where a customer reported high memory consumption in combination with the famous "Potentially excessive number of SPRequest objects (1007) currently unreleased on thread 17" message. You might notice the very high number (1007) in the message.
While analyzing the callstack of the allocation we noticed that all these SPRequest objects were allocated by a maintenance thread in SharePoint which monitors the content database for site changes to invalidate updated items in the blob cache:
at Microsoft.SharePoint.Library.SPRequest..ctor() at Microsoft.SharePoint.SPGlobal.CreateSPRequestAndSetIdentity(...) at Microsoft.SharePoint.SPWeb.InitializeSPRequest() at Microsoft.SharePoint.SPWeb.EnsureSPRequest() at Microsoft.SharePoint.SPWeb.get_Request() at Microsoft.SharePoint.SPWeb.InitWebPublic() at Microsoft.SharePoint.SPWeb.get_ServerRelativeUrl() at Microsoft.SharePoint.SPChangeCollection.InitChangeCollection() at Microsoft.SharePoint.SPChangeCollection.ConstructChangeCollection(SPChangeQuery query) at Microsoft.SharePoint.SPChangeCollection..ctor(SPSite site, SPChangeQuery query) at Microsoft.SharePoint.SPSite.GetChanges(SPChangeToken changeToken, SPChangeToken changeTokenEnd) at Microsoft.SharePoint.Publishing.BlobCache.<>c__DisplayClasse.<CheckSiteChanges>b__a() at Microsoft.Office.Server.Diagnostics.FirstChanceHandler.ExceptionFilter(...) at Microsoft.Office.Server.Diagnostics.ULS.SendWatsonOnExceptionTag(...) at Microsoft.SharePoint.Publishing.BlobCache.CheckSiteChanges(...) at Microsoft.SharePoint.Publishing.BlobCache.<>c__DisplayClass6.<LoopForChanges>b__5() at Microsoft.SharePoint.SPSecurity.CodeToRunElevatedWrapper(Object state) at Microsoft.SharePoint.SPSecurity.<>c__DisplayClass4.<RunWithElevatedPrivileges>b__2() at Microsoft.SharePoint.Utilities.SecurityContext.RunAsProcess(CodeToRunElevated secureCode) at Microsoft.SharePoint.SPSecurity.RunWithElevatedPrivileges(WaitCallback secureCode, Object param) at Microsoft.SharePoint.SPSecurity.RunWithElevatedPrivileges(CodeToRunElevated secureCode) at Microsoft.SharePoint.Publishing.BlobCache.LoopForChanges() at Microsoft.SharePoint.Publishing.BlobCache.GetCacheTokenThreadStart() at System.Threading.ExecutionContext.Run(...) at System.Threading.ThreadHelper.ThreadStart()
In MOSS 2007 the code that checks for the changes enumerates all site collections in the current web application and for each of these site collections it will instantiate an SPRequest object. After completing the check these objects will be disposed. Problems can only occur if the web application hosts a huge amount of site collections - and that will happen if the web application hosts MySites. Each MySite of a user is a separate site collection.
So it might happen that the blob cache maintenance thread will enumerate several thousand site collections and instantiate an SPSite object for each of these site collections. To avoid this problem it is highly recommended to disable blob caching for the web application that hosts the MySites on MOSS 2007.
Side Note: In SharePoint 2010 the blob cache maintenance thread has been redesigned and this problem will no longer occur.