Manchmal stellt sich die Frage, ob aktuelle Einstellungen einer (Central) Site aus Performance-Sicht auch wirklich Sinn machen. Hier ein aktuelles Beispiel einer Central Site mit ca. 1000 dynamischen Collections und deren Update-Intervallen.
Solche Betrachtungen können teilweise nicht im Vorfeld gemacht werden, da man aktuelle Werte heranziehen muss, die erst dann ermittelt werden können, wenn die betroffene Site auch wirklich in Betrieb und unter Last ist. Es macht also Sinn, die Konfiguration einer Site ab und zu kritischen Bewertungen zu unterziehen.
Wie lange braucht also der Collection Evaluator, bis er eine Collection aktualisiert hat? Glücklicherweise gibt es dazu den View v_Collection in der Datenbank:
Für jede Collection gibt es also einen Zeitstempel, an dem mit der Evaluierung begonnen wurde und einen weiteren, an dem sie abgeschlossen war. Die Mathematik überlasse ich dem SQL-Server, der mit folgender Query die Collection-Evaluierungsdauer für jede Collection berechnet:
Name AS [Collection Name],
DATEDIFF(s, EvaluationStartTime, LastRefreshTime) AS [Eval Time (s)]
FROM
v_Collection
ORDER
BY [Eval Time (s)] DESC
Somit kann man also auch den Mittelwert für die Aktualisierung pro Collection ermitteln (Stichwort: avg). In aktuellen Beispiel lag dieser bei ca. 2 Sekunden.
ConfigMgr braucht also 2000 Sekunden (2s * 1000 Collection), um alle Collections einmal zu aktualisieren. 2000s sind nach Adam Riese (oder auch dem Taschenrechner/calc.exe von Windows 7, der in der wissenschaftlichen Ansicht auch div. Umrechnungen vornehmen kann) also 33,3min:
Der Collection-Evaluator kann leider die Aktualisierungen nur sequentiell abarbeiten. Am vorliegenden Beispiel (alle Collections sind mit einem 30min Interval konfiguriert) sollte also dieser Wert definitiv erhöht werden (30min < 33min), denn die Site hat ja auch noch andere Dinge zu tun, als nur Collections zu aktualisieren.
I apologize for not replying in German. Thanks Torsten, for pointing this out to me. For any of those poor admins (like me) that have a CAS and multiple child primaries in ConfigMgr2012, here’s a potential report to run from your CAS’ SRS site, and displaying only those collections which take more than 30 seconds to run on each child primary. The child sitecodes are ABC, DEF and GHI (in the example), and the child primary servernames are sccmabc, sccmdef, sccmghi. Hopefully this is a good enough sample to help someone else, in case they need it. The ConfigMgr CEViewer tool is great, but checking multiple child primaries to find collections which are long-running on all child primaries was annoying. So an SRS report is easier for me to see.
The seconds value of 30 can be replaced with any seconds, or in an SRSreport, all of those values replaced with a @Seconds if you want to input a different value.
SELECT
ABC.collectionid as [Collection ID],
ABC.Name AS [Collection Name],
DATEDIFF(s, ABC.EvaluationStartTime, ABC.LastRefreshTime) AS [Eval Time (s) – ABC],
DATEDIFF(s, GHI.EvaluationStartTime, GHI.LastRefreshTime) AS [Eval Time (s) – GHI],
DATEDIFF(s, DEF.EvaluationStartTime, DEF.LastRefreshTime) AS [Eval Time (s) – DEF]
FROM
[SCCMABC.fully.qualified.domain.name].[cm_ABC].[dbo].[v_collection] as ABC
join [SCCMGHI.fully.qualified.domain.name].[cm_GHI].[dbo].[v_collection] as GHI on GHI.collectionid=ABC.collectionid
join [SCCMDEF.fully.qualified.domain.name].[cm_DEF].[dbo].[v_collection] as DEF on DEF.collectionid=ABC.collectionid
where
DATEDIFF(s, ABC.EvaluationStartTime, ABC.LastRefreshTime) > 30
and
ABC.collectionid in (
select GHI.collectionid from [SCCMGHI.fully.qualified.domain.name].[cm_GHI].[dbo].[v_collection] as GHI where DATEDIFF(s, GHI.EvaluationStartTime, GHI.LastRefreshTime) > 30)
and
ABC.collectionid in (
select DEF.collectionid from [SCCMDEF.fully.qualified.domain.name].[cm_DEF].[dbo].[v_collection] as DEF where DATEDIFF(s, DEF.EvaluationStartTime, DEF.LastRefreshTime) > 30)
ORDER
BY [Eval Time (s) – ABC] DESC
Hallo Torsten,
guter Hinweis zur Optimierung von SCCM Strukturen.
Nächstes Jahr soll ja alles besser werden und mit R3 wird dann ja endlich eine Delta Synchrionisation von Collection durch die Methode “Fast evaluation” eingeführt.
Bin mal gespannt wie sich dies auswirkt.
Gruß
Thorsten