Arbeitsspeicher: sichtbar (z.B. mit free) aber dennoch nicht nutzbar?

porenbeton

Lt. Junior Grade
Registriert
Nov. 2014
Beiträge
290
Hallo zusammen,

folgende Situation: ich arbeite auf einem Cluster bestehend u.a. aus GPU-Knoten mit jeweils 2 CPUs, 4 GPUs, 64 GB RAM. Ich ermittle mit einem Benchmark von NVIDIA die Rechenleistung dieser Knoten. Soweit funktioniert das auch alles.

Um den Einfluss des RAMs zu testen hat der Cluster-Administrator einen Knoten vom Netz genommen und den RAM in den Knoten GPU03 umgesteckt, welcher jetzt 128 GB RAM hat/haben sollte.

Der Befehl "free -m" liefert das folgende Ergebnis:

Code:
free -m
      total  used    free  shared  buff/cache  available
Mem: 128831   925  101431    2691       26474     123992

Kann es sein, dass obwohl der Arbeitsspeicher hier angezeigt wird, er dennoch nicht von einem Programm genutzt werden kann? Für den Benchmark gebe ich eine einheitenlose Problemgröße N vor, die ungefähr mit

Code:
vorhandener RAM muss >= N*N*8 Bytes sein

abgeschätzt werden kann. Mit 64 GB auf einem Knoten konnte ich N=85.000, mit 256 GB auf vier Knoten N=159.000 und mit 320 GB auf fünf knoten N=185.000 erreichen. Mit 128 GB auf einem Knoten habe ich eigentlich mit einem N jenseits von 100.000 gerechnet. Allerdings führt alles größer N=85.000 zu Fehlern (nicht genug Speicher), exakt wie bei 64 GB.

Wie kann ich testen, ob der Speicher wirklich nutzbar ist? Aufgrund eingeschränkter Nutzerrechte nach Möglichkeit ohne sudo oder Pakete installieren zu müssen..

Ich bin für alle Hinweise dankbar und kann falls nötig gerne noch weitere Angaben machen.

Viele Grüße
:schluck:
 
Wenn du kein Programm installieren willst, kannst du ein C-Programm schreiben und mit malloc() so viel Speicher allozieren, wie du willst.
Ansonsten gibt es fertige Tools wie http://people.seas.harvard.edu/~apw/stress/

oder dd if=/dev/zero of=/dev/shm/test bs=1k count=1024k entsprechend wie viel Speicher belegt werden soll. Wobei sich das nur soweit belegen lässt, wie es tmpfs zulässt.
 
Zuletzt bearbeitet:
eremit007 schrieb:
Code:
dd if=/dev/zero of=/dev/shm/test bs=1k count=200G

Das habe ich mal getestet, mit dem folgenden Ergebnis:

Code:
dd: error writing '/dev/shm/test': No space left on device
65728613+0 records in
65728612+0 records out
67306098688 bytes (67 GB) copied, 58.4894 s, 1.2 GB/s

Soll heißen nach 67 GB war Schluss? Liegt das am Limit von tmpfs? (Wikipedia sagt, tmpfs sei voreingestellt auf die Hälfte des vorhandenen RAMS; kann man das testen bzw. das Limit auslesen?)
 
Wikipedia sagt, tmpfs sei voreingestellt auf die Hälfte des vorhandenen RAMS; kann man das testen bzw. das Limit auslesen?)
Wenn fürs tmpfs eine andere Größe als die Voreinstellung konfiguriert wäre, sollte sie im Output von 'mount' auftauchen.

Da dein Benchmark-Programm vermulich nicht mit tmpfs arbeitet, ist der Umweg über Tests mit tmpfs eher unglücklich. Nimm lieber ein Miniprogramm als Test, was sich den Speicher auf gleiche Weise besorgt wie dein Benchmark, also z.B. mit malloc aus der glibc. Vorsicht: Bei Linux in Default-Konfiguration kannst du dir auf diese Weise mehr Speicher besorgen, als dann tatsächlich nutzbar ist.
 
Zuletzt bearbeitet:
Zurück
Oben