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

InformationsquelleAutor Namtel | 2011-08-18
Schreibe einen Kommentar