Cluster Performance

Man kann die Performance auf dem Cluster optimieren. Was man Solver(Input)seitig tun kann steht in Skalierung.Die im Folgenden angestellten Ueberlegungen gehen davon aus, dass ein typischer Knoten zur Zeit aus einem Board mit je zwei CPU's (z.B. Zwei mal Nehalem Quadcore) besteht, und Pamcrash mit dem mitgelieferten HP-MPI installiert ist.

Verteilen auf die Knoten

Ein Job, wenn moeglich, nicht auf mehrere Knoten verteilen, wenn er auf einem laufen koennte. Zwei halbe Knoten sind immer langsamer als ein ganzer, sofern dieser genuegend RAM besitzt. Einzige Ausnahme: Fuer grosse implizit Jobs mit viel Speicherplatzbedarf kann es besser sein diese auf mehrer Knoten zu verteilen um das Auslagern von Daten auf die Festplatte zu verhindern.
Sind mehrere Knoten unterschiedlicher Hardware in einem Clusterverbund zusammengeschaltet, so bestimmt der langsamste benutzte Knoten die Rechenzeit, da die Rechnung nach jedem Cycle auf den langsameren warten muss.
Haben die Knoten jeweils 8 Cores (siehe oben) so sollte mit -np 8 16 32 etc. gestartet werden. -np 10 oder 12 macht wenig Sinn, da der Performancegewinn von 8 auf 10 Prozesse durch die lansamere Netzwerkkommunikation wieder aufgebraucht wird. In einem solchen Fall kann es sogar sein, dass -np 10 langsamer ist als -np 8.

MPI Option: cpubind

Werden ein oder mehrere komplette Knoten benutzt, sollte MPI mit der Option cpubind gestartet werden.
- Beispiel: pamcrash -mpiext 'cpu_bind=v'
Hierdurch wird verhindert, dass der Sheduler des Betriebssystems die Ausfuehrung der Prozesse beliebig verteilt. Mit dieser Option wird der erste Prozess auf CPU0 gestartet und bleibt waerend der gesamten Rechenzeit an diesen Core gebunden. Dadurch hat er auch einen direkten Weg zu dem Speicherbereichbereich,der ihm beim Start zugewiesen wurde.
Werden mehrere Jobs auf einem Knoten gestartet (z.B. beide mit -np 4), dann darf cpubind nicht aktiv sein, sonst bleibt die Haelfte der Cores unbenutzt und die beiden Jobs laufen auf den gleichen Cores. Das Queuing System verwaltet Knoten und keine Cores und das MPI weiss nicht, ob bereits eine andere Rechnung auf diesem Knoten gestartet wurde.
Laeuft Pamcrash im SUD mode darf cpubind ebenfalls nicht aktiv sein, es sei denn man will das HyperThreading nutzen. Im letzteren Fall muss man aber auf die CPU MASK achten.

Pamcrash im SUD Modus (ab Version 2009)

Mit den Startparametern -np 64 -nt 2 (oder -np 32 -nt 4) werden 64 (32) DMP Prozesse mit jeweils 2 (4) Threads gestartet, d.h. jeder DMP Prozess wird nochmal SMP parallelisiert. Nach unseren Tests lohnt sich das jedoch nur bei grossen Modellen, die auf sehr vielen Cores laufen. Es ist aber auf jedenfall mal ein Versuch wert es auszuprobieren.
Obiges Beispiel (-np 64 -nt 2) kann auf 128 cores laufen, dann hat jeder Thread seinen eigenen Core (Hardware Core) und dann darf man kein cpubind aktivieren.
Ist die Anzahl der Cores der limitierende Faktor (und nicht die Anzahl der Lizenzen), dann kann man auch das HyperThreading aktueller Intel Prozessoren nutzen, das dem Betriebssystem virtuelle Cores „vorgaukelt“, es verdoppelt also die Anzahl Cores. Um bei dem obigen Beispiel zu bleiben, startet man diese 128 Threads nicht auf 128 Cores sondern nur auf 64, geht also nur mit -nt 2. Bei diesem Vorgehen sollte cpubind mit der entsprechenden CPU-MASK gesetzt sein. Das bringt auch schon bei deutlich weniger als 8 Knoten Vorteile. Bis zu 10% haben wir beobachtet, allerdings sollte das Modell nicht zu klein sein. 100000 Elemente oder mehr sollten es schon sein.

MPI und die CPU_MASK

Will man den SUD modus von Pamcrash mit der HyperThreading Option der Hardware nutzen, muss diese erstens Hardwareseitig aktiviert sein und zweitens muss man darauf achten, dass das MPI die Prozesse richtig verteilt. Jenachdem wie das BIOS die Cores durchnummeriert kann der Aufruf wie folgt lauten:

mpiext '-cpu_bind_mt=v,MASK_CPU:0f0f,f0f0'

dies ergibt sich bei folgender Nummerierung:

  CPU     Cores           Processors 
  0       0,1,2,3         (0,1)(2,3)(8,9)(10,11) 
  1       0,1,2,3         (4,5)(6,7)(12,13)(14,15) 
 
 wir packen die ersten  4 domains mit jeweils 2 threads auf cores 0,1,2,3,8,9,10,11    -> binary mask = 0000111100001111 
 wir packen die zweiten 4 domains mit jeweils 2 threads auf cores 4,5,6,7,12,13,14,15  -> binary mask = 1111000011110000

eventuell hilft auch http://www.open-mpi.org/projects/hwloc/

Bei dieser Nummerierung kann das HyperThreading gefahrlos aktiviert sein, auch wenn man es nicht nutzt, wuerde ein einfaches cpu_bind (ohne Maskierung bzw. Mapping) die ersten vier Prozesse auf CPU0 starten und die zweiten vier auf CPU1, Annahme: der Job wird mit acht gestartet (-np 8). Das entspricht also einem -cpu_bind=v,map_cpu:0,1,2,3,4,5,6,7.