Threadanzahl (MIG)

In der Migration ist es möglich manuell die Anzahl der zu verwendenen Threads anzugeben. Dabei gibt es einige Faktoren zu berücksichtigen.

Zu allererst: Mehr heißt hier nicht immer besser. Dazu später mehr. Ein Thread ist eine logische Einheit die eine Aufgabe unabhängig von anderen Faktoren abarbeiten kann.

Jede Maschine hat physische CPUs (Central Processing Unit). Dabei spricht man auch von einem “Kern” bzw. Core.

Nahezu jede moderne CPU unterstützt das sogenannte “Hyperthreading” (https://de.wikipedia.org/wiki/Hyper-Threading) Dabei wird die CPU in logische Prozessoreinheiten eingeteilt. Üblicherweise sind es zwei pro CPU (Siehe Screenshot)

Open

Diese Ansicht aus dem Taskmanager sollte auch genutzt werden um die Threadanzahl zu ermitteln.

Unter Linux wäre dies möglich mit dem Befehl:

lscpu 

Open

Rechenbeispiel:

In diesem Beispiel sehen wir einen Server, der für viele gleichzeitige Prozesse (üblicherweise Serversysteme) optimiert wurde. Das Mainboard hat 4 Sockets mit jeweils 12 Kernen. Jeder dieser Kerne hat 2 logische Threads pro Core. Hier wäre also die maximale Anzahl:

4*12*2 = 96 Threads (bei 48 Kernen). Die Herzzahl der einzelnen Kernen (hier 2.4Ghz) gibt die Geschwindigkeit an, wie schnell eine Operation abgearbeitet werden. Dabei gilt grundsätzlich: je mehr Herz, desto schneller (und desto mehr Stromverbrauch). Im Serverumfeld auf dem viele Operationen ausgeführt werden soll (wie z.B. bei der KGS Migration) spielt die Geschwindigkeit der einzelnen Kerne nur eine untergeordnete Reihe, da eine einzelne Routine selbst nicht CPU-Intensiv ist und somit auch mit geringerer Herzzahl gut auskommt. Hier fallen die 96 Threads sehr viel höher ins Gewicht.

Fazit Rechenbeispiel: Der Rechner aus dem Screenshot (Linux) kann 96 Threads parallel abbilden. Somit kann die Migration auch auf 96 Threads angehoben werden um eine optimale Auslastung zu erhalten.

Während der obere Rechner ein Desktoprechner (Windows) ist, der für wenigere Parallele Schritte aber dafür schneller (wie z.B. Office Produkte aufrufen, Browser etc.) optimiert wurde. In diesem kommen wir bereits mit 4 Threads auf die optimale Auslastung.

Was passiert wenn ich “zu wenige” oder “zu viele” Threads in der Migration angebe ?

1. Zu wenige: Im Grunde wird der Rechner nicht voll ausgenutzt. Dies kann aber u.U. gewollt sein, damit Resourcen für andere Applikationen “reserviert” bleiben. Weniger Threads führt zu einer “langsameren” Migration, da weniger gleichzeitige Operationen ausgeführt werden. Angenommen das Migrieren eines Dokuments dauert genau eine Sekunde würden wir mit 30 Threads auch 30 Dokumente pro Sekunde schaffen. Mit 96 Threads also auch 96 Dokumente pro Sekunde. Wielange eine Migration pro Dokument dauert hängt aber von weiteren Faktoren ab: Retrievalzeit des Quelldokuments (Netzwerk, Datenträger auf dem die Quelle liegt etc.) sowie die Ablagezeit ins Ziel (Netzwerk, Datenträger auf dem Zielarchiv. S3 z.B. gilt nicht als das performanteste System).

2. Zu viele: Werden mehr Threads angefordert als der Rechner tatsächlich Besitzt/Zugriff hat, so findet in der Maschine ein “switch” zwischen den Threads statt. Das ist in der Realtiät effektiv immer gegeben. Im Windows-Screenshot kann man die Threadzahl 3916 sehen. Diese ist die Summe Threads aller Prozesse (Programme, hier: 334) die aktuell genutzt werden. Würden einige dieser Threads 100% CPU benutzen hätte dies einen Einfluss auf die anderen Threads, denn erst dann nimmt der Thread mit den 100% CPU Last den anderen Threads die Resourcen weg. Ist dies nicht der Fall (angenommen jeder Thread braucht nur 0.5 % CPU) wird dieser Prozess abgearbeitet und zum nächsten Thread gewechselt und dieser abgearbeitet. Dieser Prozess nennt man auch Kontextwechsel (https://de.wikipedia.org/wiki/Kontextwechsel )

Wie verhält es sich mit mehreren Webapps / Webservern auf der gleichen Maschine ?

Da sich die physische Hardware nicht ändert müssen sich Programme auf einem Server/Rechner auch die gleichen Resourcen teilen. Dabei tritt der Effekt des Kontextwechsels (siehe Punkt 2 “zu viele”) auf. Somit ist es ebenso nicht ratsam mehrere Webapps / Webserver zu deployen auf der gleichen Maschine mit der maximalen Threadzahl. Es gilt also optimal: Anzahl der logischen Threads der Maschine / Anzahl der Webapplikationen mit jeweils entsprechenden Threads. Kurz: Zwei Migrationen auf dem gleichen Server zu je 2 Threads hat den gleichen (optimalen) Effekt wie eine Migration mit 4 Threads (insofern das System nur 4 logische Threads unterstützt). Bei 96 Threads wiederrum wäre das Optimum für zwei Migrationen also jeweils 48 Threads.

Fazit:

Es ist empfohlen sich die Hardwarespezifikationen entweder über den Taskmanager oder bei Linux über den Befehl lscpu  ausgeben zu lassen. Der hier angegebene Wert sollte als Richtlinie für die Anzahl der Threads genutzt werden. Eine zu hohe “Fantasie”-Zahl führt zum negativen Effekt. Zu wenige Threads sorgt für eine langsame Migration da die Resourcen nicht voll ausgenutzt werden.