Wie kann ich dieses Problem beheben memory leak in meinem SharePoint Powershell-Skript?
Zweck des Skripts: aufgrund unserer Active-Directory-Infrastruktur, fügen wir über 6000 Einträge direkt auf der Seite User-Info-Liste, so dass Sie dargestellt werden, im Adressbuch in der SharePoint Personenauswahl.
Das Skript legt über 6000 SPUser-Objekte, um Sie in der Site-User-Info-Liste. Die meisten von Ihnen bereits existieren, in diesem Fall neuen-SPUser sollten nichts tun, richtig?
EDIT: bitte hinterlassen Sie ein feedback oder eine mögliche Lösung. Ich entfernte einige der großen log für bessere übersicht und Hinzugefügt einige details. Vielleicht kennt Ihr ein anderes forum wo ich posten soll diese Frage?
Ich bekomme viele Nachrichten, wie diese:
Potenziell übermäßige Anzahl von SPRequest-Objekten (20) derzeit
unveröffentlichte thread 9. Sicherstellen, dass das Objekt oder dessen Elternteil (Z
als ein SPWeb oder SPSite), ordnungsgemäß zu entsorgen. Dieses Objekt ist
das festhalten an einem separaten nativen heap.Dieses Objekt wird nicht
automatisch entsorgt. Zuweisung Id für dieses Objekt: {...snip...} Stack
Spur der aktuelle Vergabe: an
Microsoft.SharePoint.SPGlobal.CreateSPRequestAndSetIdentity(SPSite
Ort, String name, Boolean bNotGlobalAdminCode, String strUrl, Boolean
bNotAddToContext, Byte[] UserToken, String userName, Boolean
bIgnoreTokenTimeout, Boolean bAsAnonymous)
...snip...
Und viele Botschaften wie diese:
08/17/2011 19:38:35.26 PowerShell.exe (0x1388) 0x20C0 SharePoint Foundation Performance nask Überwachbar Eine SPRequest-Objekt freigegeben wurde durch den garbage collector anstatt explizit freigegeben. Zur Vermeidung der Verschwendung von system-Ressourcen, entsorgen Sie dieses Objekt oder seine Eltern (wie ein SPWeb, SPSite oder), sobald Sie fertig sind es zu benutzen. Vergabe-Id: {09C61E87-2BA1-4CEA-BB3C-266A1345559A} Zu bestimmen, wo das Objekt zugewiesen wurde, legen Sie die Microsoft.SharePoint.Verwaltung.SPWebService.ContentService.CollectSPRequestAllocationCallStacks = true. de663eab-8063-4381-88b5-01cc50d51b77
Dies ist das aktuelle Skript mit hervorgehobenen vier Linien ( # ***
), die wir Hinzugefügt, um es zu lösen (hat nicht funktioniert).
Write-Host "Fill Site User Info List for "$args[0]
add-pssnapin microsoft.sharepoint.powershell -ErrorAction SilentlyContinue
Start-SPAssignment -Global # ***
#global properties
$ppFilter = "(...)"
get-date
$ldapFilter = "(...)"
$ldapDirectory = "LDAP://DC=..."
Write-Host "Get all users from ..."
$de = New-Object system.directoryservices.directoryentry($ldapDirectory)
$de
$newsearch = New-Object System.DirectoryServices.DirectorySearcher($de)
write-host "Filter all active users with ..."
$newsearch.Filter = $ldapFilter
$newsearch.PageSize = 200
$result = $newsearch.FindAll()
write-Host "Get all domain user accounts..."
$useraccounts = $result | % {"..."}
$siteCollection = get-spsite $args[0]
$webApp = $siteCollection.WebApplication
Write-Host "clear people picker filter" $webApp.Name "..."
$webApp.peoplepickersettings.ActiveDirectoryCustomFilter = ""
$webApp.Update()
write-Host "---------------"
$siteUrl = $siteCollection.Url
Write-Host "add "$useraccounts.Count" users to site collection "$siteUrl "..."
$start = get-date
$site = $siteCollection.RootWeb # ***
foreach ($user in $useraccounts) {
$current = New-SPUser -UserAlias $user -Web $site # *** was before: $siteUrl
}
$end = get-date
$end - $start
$SiteCollection.Dispose()
Write-Host "---------------"
Write-Host "set people picker filter to" $ppFilter "..."
$webApp.peoplepickersettings.ActiveDirectoryCustomFilter = $ppFilter
$webApp.Update()
Stop-SPAssignment -Global # ***
Write-Host "Done."
get-date
Gibt es einen offensichtlichen Fehler, den wir gemacht? Danke für die Anregungen.
In Antwort auf @x0n poste ich einen größeren Teil des Protokolls. Sorry für diese nicht lesbar formatieren. Gibt es einen besseren Weg, um logs posten? Alle Zeilenumbrüche und tab-Bereiche sind Durcheinander.
Der Punkt ist, dass die Nachrichten über zurückgefordert SPRequest-Objekt kommt von den powershell-Prozess. Ich bin absolut sicher, dass dieses Skript war der einzige, der läuft. Dieses Skript verwendet, um die Oberfläche in weniger als 10 Minuten, aber jetzt ist es nicht fertig, auch nach 1,5 Stunden. Ich bin mir ziemlich sicher, ich habe nichts ändern, das Skript, das verändert das Verhalten. Die performance-Ansicht der Windows-Task-Manager zeigte eine moderate Belastung auf die CPU und der Recht hohe Verbrauch von RAM (nicht den ganzen Weg zu 100%), während das Skript ausgeführt wurde.
Zeitstempel Prozess-TID-Bereich der Kategorie EventID-Level-Meldung Korrelation
08/17/2011 19:38:34.30 PowerShell.exe (0x1388) 0x20C0 SharePoint Foundation PowerShell 6tf0 Medium Eingabe EndProcessing Methode der New-SPUser.
08/17/2011 19:38:34.30 PowerShell.exe (0x1388) 0x20C0 SharePoint Foundation PowerShell 6tf0 Medium Verlassen EndProcessing Methode der New-SPUser.
08/17/2011 19:38:34.30 PowerShell.exe (0x1388) 0x20C0 SharePoint Foundation PowerShell 6tf0 Medium Eingabe BeginProcessing Methode der New-SPUser. de663eab-8063-4381-88b5-01cc50d51b77
08/17/2011 19:38:34.30 PowerShell.exe (0x1388) 0x20C0 SharePoint Foundation PowerShell 6tf0 Medium Verlassen BeginProcessing Methode der New-SPUser. de663eab-8063-4381-88b5-01cc50d51b77
08/17/2011 19:38:34.30 PowerShell.exe (0x1388) 0x20C0 SharePoint Foundation PowerShell 6tf0 Medium Eingabe der ProcessRecord-Methode der New-SPUser. de663eab-8063-4381-88b5-01cc50d51b77
08/17/2011 19:38:34.30 PowerShell.exe (0x1388) 0x20C0 SharePoint Foundation Performance naqx Überwachbar Potenziell übermäßige Anzahl von SPRequest-Objekten (19), die derzeit unveröffentlichte thread 9. Sicherstellen, dass das Objekt oder seine Eltern (wie ein SPWeb oder SPSite), ordnungsgemäß zu entsorgen. Dieses Objekt ist das festhalten an einem separaten nativen heap.Dieses Objekt wird nicht automatisch entsorgt. Zuweisung Id für dieses Objekt: {815F9A3D-6635-42FA-9658-B6294968136E} Stack-trace des aktuellen Allokation: bei Microsoft.SharePoint.SPGlobal.CreateSPRequestAndSetIdentity(SPSite site, String name, Boolean bNotGlobalAdminCode, String strUrl, Boolean bNotAddToContext, Byte[] UserToken, String userName, Boolean bIgnoreTokenTimeout, Boolean bAsAnonymous) bei Microsoft.SharePoint.SPRequestManager.GetContextRequest(SPRequestAuthenticationMode authenticationMode) bei Microsoft.SharePoint.Verwaltung.SPFarm.g... de663eab-8063-4381-88b5-01cc50d51b77( .... snip ....)
08/17/2011 19:38:34.30 PowerShell.exe (0x1388) 0x20C0 SharePoint Foundation Performance naqx Überwachbar Potenziell übermäßige Anzahl von SPRequest-Objekten (19), die derzeit unveröffentlichte thread 9. Sicherstellen, dass das Objekt oder seine Eltern (wie ein SPWeb oder SPSite), ordnungsgemäß zu entsorgen. Dieses Objekt ist das festhalten an einem separaten nativen heap. Zuweisung Id für dieses Objekt: {F9CDF3DA-41B1-485D-B78F-0266545C417A} Stack-trace des aktuellen Allokation: bei Microsoft.SharePoint.SPGlobal.CreateSPRequestAndSetIdentity(SPSite site, String name, Boolean bNotGlobalAdminCode, String strUrl, Boolean bNotAddToContext, Byte[] UserToken, String userName, Boolean bIgnoreTokenTimeout, Boolean bAsAnonymous) bei Microsoft.SharePoint.SPWeb.InitializeSPRequest() bei Microsoft.SharePoint.SPWeb.InitWebPublic() bei Microsoft.SharePoint.SPWeb.get_Exists() bei Microsoft.SharePoint.PowerShell.SPWebPipeBind.Rea... de663eab-8063-4381-88b5-01cc50d51b77
(... snip ...)
(... viele Nachrichten: )
08/17/2011 19:38:35.26 PowerShell.exe (0x1388) 0x20C0 SharePoint Foundation Performance nask Überwachbar Eine SPRequest-Objekt freigegeben wurde durch den garbage collector anstatt explizit freigegeben. Zur Vermeidung der Verschwendung von system-Ressourcen, entsorgen Sie dieses Objekt oder seine Eltern (wie ein SPWeb, SPSite oder), sobald Sie fertig sind es zu benutzen. Vergabe-Id: {09C61E87-2BA1-4CEA-BB3C-266A1345559A} Zu bestimmen, wo das Objekt zugewiesen wurde, legen Sie die Microsoft.SharePoint.Verwaltung.SPWebService.ContentService.CollectSPRequestAllocationCallStacks = true. de663eab-8063-4381-88b5-01cc50d51b77
Du musst angemeldet sein, um einen Kommentar abzugeben.
Diese Meldung nicht tatsächlich angeben, dass ein Leck - das wichtigste hier ist das Wort "möglicherweise." Allen, die Meldung bedeutet, dass dein thread hat eine Menge in der gleichen Zeit geöffnet. Die Schwelle für den Ausstoß, die Nachricht ist eigentlich ziemlich niedrig für den praktischen Einsatz. Was wirklich wichtig ist, dass Sie entsorgt werden korrekt am Ende Ihrer Lebensdauer. Wenn Sie wirklich ein Leck hatte, würden Sie sehen, Meldungen wie diese:
Stefan Grossner hat einen tollen Artikel erklären die Argumentation hinter all dies, einschließlich der Grund, warum der Schwellenwert für die Warnung ist wohl zu niedrig ist (und wie Sie es ändern können, um etwas mehr praktisch.)
http://blogs.technet.com/b/stefan_gossner/archive/2008/05/07/troubleshooting-spsite-spweb-leaks-in-wss-v3-and-moss-2007.aspx
Übrigens, auch wenn Sie haben ein Leck, und Sie konnte ihn nicht finden, schließen Sie den powershell-Prozess zurückkehren wird, den Speicher.
Hoffe, das hilft.
System.DirectoryServices
auch nicht verwaltete Objekte nutzt.Müssen Sie entsorgen Ihre directoryentry-und directorysearcher-Objekte, und ich denke, auch die searchresultcollection-Auflistung-Objekt wird implizit erstellt von powershell auf Ihrem Namen.
Sollten Sie entsorgen SP-Objekte, vor allem SPWeb und SPSite gezielt.
Best practices Referenz:
http://blogs.msdn.com/b/rogerla/archive/2008/02/12/sharepoint-2007-and-wss-3-0-dispose-patterns-by-example.aspx
http://msdn.microsoft.com/en-us/library/aa973248.aspx
Problem Referenz Blog:
http://blogs.technet.com/b/stefan_gossner/archive/2008/05/07/troubleshooting-spsite-spweb-leaks-in-wss-v3-and-moss-2007.aspx
VS-plugin zu erkennen Sharepoint-Lecks:
https://spdisposecheck2012.codeplex.com/