Mit der Installation des Infiniband-Clusters der Firma Megware im Februar 2011 steht den Nutzern des Instituts ISUT und anderen Instituten der Universität ein Hochleistungsrechen-Cluster mit ausreichend Hauptspeicher und Parallelisierungsmöglichkeit zur Verfügung. Die Comp2 ist für spezielle Anwendungen mit hohen Anforderungen an Netzwerk-Bandbreite und Compute-Leistungen bestimmt. Gleichzeitig ist der Stromverbrauch bezogen auf Performance und Hauptspeicher sehr günstig.
| Architektur: | Infiniband-Cluster aus 16-Core-Nodes |
| Prozessor (CPU): | 44x 8-Core-Opteron 6134 - 2300MHz |
| Hauptspeicher (RAM): | 22x 128 Gbytes (8GB/Core ECC-DDR3-1333) |
| Festplatten (HD): | 22 x 1 TBytes Scratch, zentrales 20 TB RAID5 Home |
| Netzwerkanschluss: | 22 x QDR-IB + 1Gb-Ethernet |
| Stromverbrauch: | 4.5 kW (idle) - 8 kW (full load) |
| Besonderheiten: | Messung Stromverbrauch, Raumtemperatur und Feuchtigkeit |
--- ACHTUNG --- muss noch ueberarbeitet werden --- ACHTUNG ---
ssh -X comp2.mb.uni-magdeburg.de # login to master via ssh-key
pbstop # text based job overview, "q" for quit
# shows wrong CPU number if job is submitted on specific nodes
# mpi-selector --set openmpi_gcc-1.4.2 # einmalig aufzurufen
module avail
module load openblas/0.2.14
module load gcc-4.9.2
module load mpi/gcc/openmpi-1.8.4
module list
mpicc -O2 -o mpiprog mpiprog.c # compile parallel program
qsub -I -l nodes=10:ppn=16 # starting interactive Job, "Ctrl-d" for quit
# ppn = processes per node (maximum 16)
# max. 22*16 = 352 tasks
# login to first available node
mpiexec -f $PBS_NODEFILE -np $(cat $PBS_NODEFILE | wc -l) ./mpiprog
# starting your parallel program
#!/bin/bash # join stderr to stdout and set max. realtime to 24h or what you need # memory is total_memory / MPI_tasks, max: 8gb(ppn=16) or 128gb(ppn=1) # output of stderr and stdout will be jobscript.oNNN # #PBS -j oe #PBS -l walltime=24:00:00 # # set ulimit -v to 4gb virtual memory per mpi-task # max. per node is 126gb (2gb left for the system) #PBS -l vmem=30000mb,mem=30000mb # # set paths to extra software/libraries when needed: module load openblas/0.2.14 module load gcc-4.9.2 module load mpi/gcc/openmpi-1.8.4 module list # echo "DBG: pwd=$(pwd) PBS_O_WORKDIR=$PBS_O_WORKDIR" cd $PBS_O_WORKDIR NP=$(cat $PBS_NODEFILE | wc -l) # reduce ulimit to 4gb, because qsub sets ulimit -v to max(vmem,mem) ulimit -v $(( $(ulimit -v) / $NP )) echo "ulimitv=$(ulimit -v) NP=$NP" # output for debugging # ulimit -v 7800000 # for ppn=16: 16*7.8GB=125GB # ulimit -v 120000000 # for ppn=1: 120GB # mpiexec --hostfile $PBS_NODEFILE -np $NP ./mpiprog
qsub -l nodes=10:ppn=16 jobscript # start 160 processes on 10 nodes qsub -l nodes=node001:ppn=16 jobscript # start 16 processes on node001 # stop jobs by: qdel $jobnumber # please adapt the CPU needs to your memory needs (CPUs=memory/8GB) # if you dont need much memory, let a minimum of one CPU per node free for # those users, which need a lot of memory (for example ppn=7) # for maximum overall efficiency of the cluster, thanks # contact Joerg Schulenburg Tel. 18408 for help
Der Zugang erfolgt aus der UNI-Domain über ssh comp2.mb.uni-magdeburg.de (IP=141.44.132.2, see OpenSSH, PuTTY). Wenn Sie Windows und Excced für den Zugang (grafisch) benutzen, beachten Sie bitte die Konfigurationshinweise des URZ. Accounts können ueber Herrn Woche oder Herrn Gille per EMAIL beantragt werden. Für Fragen und Probleme wenden Sie sich bitte an mailto:Joerg.Schulenburg((at))URZ.Uni-Magdeburg.DE?subject=WWW-Comp2 oder Tel.18408.
17.02.11 - Lieferung und Inbetriebnahme durch Megware
14.03.11 - Probleme node06 (sporadisch reboots)
16.03.11 - node15 down, reboots nach 5-90s
18.03.11 - Konfiguration grub + agetty fuer IPMI.ttyS1
24.03.11 - Knoten 5+6 wieder eingebaut (hatte Kontaktprobleme RAM?)
24.03.11 - Knoten 15+16 zur Reparatur (defektes Speichermodul identifiziert)
29.03.11 - Knoten 15 zurueck, defektes Speichermodul wurde getauscht
18.04.11 - Reboot + Bios-Config Nodes ipmi.LAN1=static (DHCP-Logs=100MB/7d)
- pbs_mom disabled on frontend (bad entries in log-file)
10.05.11 - shutdown wegen Ausfall Klima
01.06.11 - Abschaltung der Knoten wegen Klimaausfall
03.06.11 - Komplettabschaltung wegen Klimaausfall bis vorraussichtlich 7.6.
22.06.11 - node13 spontaner(?) reboot um 15:01
23.06.11 - node21 spontaner(?) reboot um 10:28
23.06.11 - node13 spontaner(?) reboot um 18:35
24.06.11 - node13 spontaner(?) reboot um 02:14, Ursache unklar
26.06.11 - node13 10:03 crash (network?)
28.06.11 - node13 power off + on, alte Prozesse (mpi-connect to node13) gekillt
29.06.11 - node13 04:13 offline, spontaner reboot 04:14 + 04:32 (load=0)
- node13 10:48 spontaner(?) reboot, 10:51 kernel traces
05.07.11 - node19 crashed (OOM = Out-of-Memory)
06.07.11 - node22 crashed (gleiches Programm, OOM = Out-of-Memory)
06.07.11 - node13 defekt (reboots oder VGA=tot in bios oder memtest)
22.07.11 - node13 defekter Stromverteiler (Power Distributor) getauscht
18.07.12 - Stromausfall (eine Phase, node1-8)
25.07.12 - Stromausfall (2 Phasen, incl. Master, Clustsafe defekt?)
28.08.12 - Uniweiter Spannungsdrop 03:41:41, Knotenausfall
11.09.12 - Automatische Abschaltung wegen RF=80%
(Default nach Reparatur ClustSafe, neuer Grenzwert 90%RF Kaltluft)
18.09.12 - node03 SATA-Error + Crash, reboot + monitoring
23.09.12 - Klimaausfall + Notabschaltung bei 33C
25.09.12 - Anschlusswechsel zur USV, temporaere Entlastung Sicherung
27.09.12 - mehrfache Crashs node03 auch wenn nur idle
02.11.12 - node03 nach Reparatur (Plattentausch) neu aufgesetzt
14.01.13 - 9 spontane reboots node03 + crash, idle (SATA + khubd panics)
08.03.13 - node03 ohne Fehlerbefund wieder eingebaut (monitored)
10.03.13 - node20 aufgehangen (keine Ursachen sichtbar, monitored)
02.05.13 - node03 erneut spontaner reboot
28.05.13 - Datenfehler node16+22 ab ca. 2.5. nfs error 88, reboot + set overcommit_ratio=98%
18.06.13 - node19 node 3.0 K8 ECC error
25.06.13 - node20 aufgehangen (13:18) console: amd64_edacError Overflow
01.07.13 - node20 ECC-Fehler + 1 crash, node19+20 zur Reparatur RAM
0x.07.13 - node10 ECC-Fehler (bisher ohne Auswirkungen)
08.07.13 - node20 fehlerhaftes RAM-Modul ersetzt
05.09.13 - ansys14 installed
20.09.13 - node10 repariert, RAM getauscht (laengere Fehlersuche)
25.06.14 - job-Abbruch wegen disconnect Gb-eth (i82574L mod=e1000e TSO?)
28.06.14 - node20 ipmi nicht erreichbar (21:44-23:44)
17.09.14 - bei Netzwartung Netzwerkkabel versehentlich gezogen (30h offline)
19.09.14 - Stromabschaltung wegen Wechsel der USV
23.09.14 - node10 startet nicht (power distributer defect, to repair)
04.03.15 - Gb-Switch getauscht (zunehmende Ausfaelle Ports seit 2013)
15.04.16 - install openblas modules, best openblas/0.2.14
04.10.16 - Ausfall, IB-card node12, 07.10. node12 off+on, OK
05.10.17 - Stromaussetzer (Sturmfront) Knoten off
29.10.17 - Stromaussetzer (Sturmfront) Knoten +USV+Master off (ClustSafe error)
05.12.17 - Stromaussetzer, Knoten off (3x2016,7x2017 max=70s)
30.12.17 - Ausfall Sicherung S1 (alle Switche power off)
02.01.18 - nach einschalten S1 master gecrasht, pwr=on, dsk+usb+vga+eth+ib=off
02.01.18 - nach reset wieder ok, Stromversorgung ipmi-switch + PSU1 via bigUSV
16.10.18 - 13:56 lokaler Spannungsdrop, USV zieht Sicherung S1, Nodes down
14.06.20 - letzte regulaere Jobs, Ausfall 2er disks (raid6 still working)
16.09.20 - master node crashed, reset ok, storage zeroed, nodes set down
Uns sind im Laufe der Zeit folgende Probleme
aufgefallen:
(1) bei Auftreten von Out-of-Memory (OOM) auf einem Knoten,
funktioniert der OOM-Killer nicht und kernel panic tritt auf (OOM-dead),
mittels Testprogrammen kann man den OOM-dead in 20-30s ausloesen,
der Knoten bleibt nicht erreichbar,
ausserdem funktioniert das Rueckschreiben des
Job-Outputfiles bei weiteren Jobs nicht mehr bis zum Reboot des Knotens,
auf console erscheint:
node01.service login: nfs: RPC call returned error 88
nfs: RPC call returned error 88
INFO: task ypbind:5464 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
ypbind D ffff81083c13b7a0 0 5464 1 5482 5461 (NOTLB)
# kernel 2.6.18-194
# d.h. OOM-Situationen bitte unbedingt vermeiden!
Workarround (tested +buffer+cache+/dev/shm) for /etc/sysctl.conf:
vm.overcommit_memory = 2
vm.overcommit_ratio = 98
echo 98 > /proc/sys/vm/overcommit_ratio # 98% for use, 2% for nfsd...
echo 2 > /proc/sys/vm/overcommit_memory # no overcommit memory!
(2) spontane reboots, node13 (nach PDU-Tausch ok), node03 (wegen ECC, behoben)
(3) ECC-Errors (meist ohne Auswirkungen)
(4) spontane disconnects eth0 on Nodes, Vermutung: TSO-Problem?
fuehrt selten zu Job-Abbruechen
TSO abschalten hilft nicht
tritt bei starkem NFS-Traffic auf (MTU=1500, nfs-block-size=8k)
Links: ISUT-SMP-Rechner comp1,
ITP-Cluster quantum,
URZ-SMP-Rechner meggie,
URZ-MIPS-Cluster kautz
Author: Joerg Schulenburg, Uni-Magdeburg URZ, Tel. 18408 (2011-06-03)