Auch wenn dieser Thread relativ alt ist, das Problem der hohen CPU-Auslastung bei SharePoint 2010 kommt ja öfter vor.
Eine manuelle Begrenzung ist ab Windows Server 2008 aufwärts in gewissen Grenzen machbar, erfordert aber einiges Probieren, bis die optimalen Werte gefunden werden. Hierzu ist es wichtig, dass die einzelnen Services und die einzelnen Application Pools
nicht unter dem selben Account laufen, weil die Maßnahmen nur gemeinsam greifen.
- Verteilen der IIS Application Pools auf die unterschiedlichen CPUs:
- Zunächst im IIS in die Advanced Settings des jeweiligen Application Pools gehen.
- Dort Processor Affinity Enabled auf TRUE setzen.
- Die Processor Affinity Mask auf den gewünschten Wert setzen:
Nehmen wir an, wir haben 8 Cores, dann entspricht das einer Binärmaske von 00000000, wobei der erste Prozessor durch das rechteste Bit repräsentiert wird. Sollen also nur Core 1 und 3 benutzt werden dürfen, dann wäre die gewünschte Maske 00000101. Als Dezimalwert
ist das dann 5. Das muss gesetzt werden. - Beschränken der möglichen Gesamt-CPU-Nutzung pro Account (s.
http://technet.microsoft.com/en-us/library/ff384148(WS.10).aspx ):
Eine Beschränkung einzelner Prozesse ist nicht möglich, aber eine Beschränkung pro Account. Gerader der extrem hungrige
SharePoint Timer Service (OWSTIMER.EXE), oder der Web Analytics Service laufen meist unter separaten Dienstaccounts. Um einen Account zu beschränken geht man wie folgt vor:
- SID des Accounts herausfinden: wmic useraccount get name,sid
- Registry Key erzeugen: HKLM\System\CurrentControlSet\Control\Session Manager\Quota System\<SID>
- Limit eintragen: Unterhalb des neuen Keys den D-Word Value CpuRateLimit auf den Dezimalwert für die gewünschte prozentuale Nutzung setzen (1-100)
Man muss hier etwas Fingerspitzengefühl entwickeln. Ordnet man z.B. bei unseren 8-Core Beispiel die Application Pools so zu, dass ein Pool exclusiven Zugriff auf einen Kern erhält und andere Cores mitbenutzen darf, so muss klar sein, dass ein Kern 12,5%
der gesamten CPU-Leistung des Systems sind.
Es gibt noch weitere Hürden. Z.B. läuft der SharePoint Timer Service (v4) im Regelfall unter dem zentralen Account der ganzen Farm. Will man das ändern muss man:
- Einen neuen Account anlegen, i.d.R. im Active Directory
- Dem neuen Account auf dem SharePoint Server, in der SQL Instanz, die die Farm verwendet und auf den Datenbanken dieser Instanz die selben Rechte vergeben, die auch der Farm Account besitzt
- Diesen Account zum SharePoint Managed Account machen: Central Administration Website -> Security -> Configure Managed Accounts
- Den Service Account des Timer Service ändern. Zum einen natürlich via Services.msc, aber auch in SharePoint selber. Dies geht nur über die
Share Point Management Shell:
$SPService = "SPTimerV4"
$SPManagedAccount = "DOMÄNE\Dienstaccount"
$SPFarm = Get-SPFarm
$SPTimerv4 = $SPFarm.Services | Where {$_.Name -eq $SPService}
$SPTimerv4NewManagedAccount = Get-SPManagedAccount $SPManagedAccount
$SPTimerv4.ProcessIdentity.CurrentIdentityType = "SpecificUser"
$SPTimerv4.ProcessIdentity.ManagedAccount = $SPTimerv4NewManagedAccount
$SPTimerv4.ProcessIdentity.Update()
Manche Adminstratoren möchten den Timer Service via Scheduled Tasks recyclen. Man kann natürlich den gesamten Dienst neu starten, aber hier werden Jobs natürlich hart abgebrochen. Besser ist es, die eingebaute Recycling-Funktion zu verwenden. Diese ist hier
http://adayinsharepointv3.blogspot.de/2012/10/recycling-sharepoint-timer-service.html sehr schön beschrieben. Bitte auch beachten, dass es u.U. sinnvoll ist, die Zeit, die der Dienst vor den Recycling neue Anfragen blockiert und abwartet, von 10 Minuten
etwas zu reduzieren.
Wie gesagt, das sind letztendlich nur Workarounds aus Sicht eines Systemverantwortlichen. Letztendlich kommt man um eine Analyse mit den Applikationsentwicklern, ob bestimmte Applikation unsauber Ressourcen belegen, nicht herum.
Viele Grüße
Guido Alexius
