AMD 24 Core Server Speicherbandbreite


7

Ich benötige Hilfe, um festzustellen, ob die unter Linux auf meinem Server angezeigte Speicherbandbreite normal ist oder nicht. Hier ist die Serverspezifikation:

HP ProLiant DL165 G7
2x AMD Opteron 6164 HE 12-Core
40 GB RAM (10 x 4GB DDR1333)
Debian 6.0

Bei Verwendung mbwauf diesem Server erhalte ich folgende Nummern:

foo1:~# mbw -n 3 1024
Long uses 8 bytes. Allocating 2*134217728 elements = 2147483648 bytes of memory.
Using 262144 bytes as blocks for memcpy block copy test.
Getting down to business... Doing 3 runs per test.
0   Method: MEMCPY  Elapsed: 0.58047    MiB: 1024.00000 Copy: 1764.082 MiB/s
1   Method: MEMCPY  Elapsed: 0.58012    MiB: 1024.00000 Copy: 1765.152 MiB/s
2   Method: MEMCPY  Elapsed: 0.58010    MiB: 1024.00000 Copy: 1765.201 MiB/s
AVG Method: MEMCPY  Elapsed: 0.58023    MiB: 1024.00000 Copy: 1764.811 MiB/s
0   Method: DUMB    Elapsed: 0.36174    MiB: 1024.00000 Copy: 2830.778 MiB/s
1   Method: DUMB    Elapsed: 0.35869    MiB: 1024.00000 Copy: 2854.817 MiB/s
2   Method: DUMB    Elapsed: 0.35848    MiB: 1024.00000 Copy: 2856.481 MiB/s
AVG Method: DUMB    Elapsed: 0.35964    MiB: 1024.00000 Copy: 2847.310 MiB/s
0   Method: MCBLOCK Elapsed: 0.23546    MiB: 1024.00000 Copy: 4348.860 MiB/s
1   Method: MCBLOCK Elapsed: 0.23544    MiB: 1024.00000 Copy: 4349.230 MiB/s
2   Method: MCBLOCK Elapsed: 0.23544    MiB: 1024.00000 Copy: 4349.359 MiB/s
AVG Method: MCBLOCK Elapsed: 0.23545    MiB: 1024.00000 Copy: 4349.149 MiB/s

Auf einem meiner anderen Server (basierend auf Intel Xeon E3-1270):

foo2:~# mbw -n 3 1024
Long uses 8 bytes. Allocating 2*134217728 elements = 2147483648 bytes of memory.
Using 262144 bytes as blocks for memcpy block copy test.
Getting down to business... Doing 3 runs per test.
0   Method: MEMCPY  Elapsed: 0.18960    MiB: 1024.00000 Copy: 5400.901 MiB/s
1   Method: MEMCPY  Elapsed: 0.18922    MiB: 1024.00000 Copy: 5411.690 MiB/s
2   Method: MEMCPY  Elapsed: 0.18944    MiB: 1024.00000 Copy: 5405.491 MiB/s
AVG Method: MEMCPY  Elapsed: 0.18942    MiB: 1024.00000 Copy: 5406.024 MiB/s
0   Method: DUMB    Elapsed: 0.14838    MiB: 1024.00000 Copy: 6901.200 MiB/s
1   Method: DUMB    Elapsed: 0.14818    MiB: 1024.00000 Copy: 6910.561 MiB/s
2   Method: DUMB    Elapsed: 0.14820    MiB: 1024.00000 Copy: 6909.628 MiB/s
AVG Method: DUMB    Elapsed: 0.14825    MiB: 1024.00000 Copy: 6907.127 MiB/s
0   Method: MCBLOCK Elapsed: 0.04362    MiB: 1024.00000 Copy: 23477.623 MiB/s
1   Method: MCBLOCK Elapsed: 0.04262    MiB: 1024.00000 Copy: 24025.151 MiB/s
2   Method: MCBLOCK Elapsed: 0.04258    MiB: 1024.00000 Copy: 24048.849 MiB/s
AVG Method: MCBLOCK Elapsed: 0.04294    MiB: 1024.00000 Copy: 23847.599 MiB/s

Als Referenz bekomme ich Folgendes auf meinem Intel-basierten Laptop:

laptop:~$ mbw -n 3 1024
Long uses 8 bytes. Allocating 2*134217728 elements = 2147483648 bytes of memory.
Using 262144 bytes as blocks for memcpy block copy test.
Getting down to business... Doing 3 runs per test.
0   Method: MEMCPY  Elapsed: 0.40566    MiB: 1024.00000 Copy: 2524.269 MiB/s
1   Method: MEMCPY  Elapsed: 0.38458    MiB: 1024.00000 Copy: 2662.638 MiB/s
2   Method: MEMCPY  Elapsed: 0.38876    MiB: 1024.00000 Copy: 2634.043 MiB/s
AVG Method: MEMCPY  Elapsed: 0.39300    MiB: 1024.00000 Copy: 2605.600 MiB/s
0   Method: DUMB    Elapsed: 0.30707    MiB: 1024.00000 Copy: 3334.745 MiB/s
1   Method: DUMB    Elapsed: 0.30425    MiB: 1024.00000 Copy: 3365.653 MiB/s
2   Method: DUMB    Elapsed: 0.30342    MiB: 1024.00000 Copy: 3374.849 MiB/s
AVG Method: DUMB    Elapsed: 0.30491    MiB: 1024.00000 Copy: 3358.328 MiB/s
0   Method: MCBLOCK Elapsed: 0.07875    MiB: 1024.00000 Copy: 13003.670 MiB/s
1   Method: MCBLOCK Elapsed: 0.08374    MiB: 1024.00000 Copy: 12228.034 MiB/s
2   Method: MCBLOCK Elapsed: 0.07635    MiB: 1024.00000 Copy: 13411.216 MiB/s
AVG Method: MCBLOCK Elapsed: 0.07961    MiB: 1024.00000 Copy: 12862.006 MiB/s

Also laut mbw meinem Laptop ist 3 mal schneller als der Server !!! Bitte helfen Sie mir, dies zu erklären. Ich habe auch versucht, eine RAM-Disk zu mounten und sie mit dd zu bewerten, und ich bekomme ähnliche Unterschiede, daher glaube ich nicht, dass dies mbwdie Schuld ist.

Ich habe die BIOS-Einstellungen überprüft und der Speicher scheint mit voller Geschwindigkeit zu laufen. Laut Hosting-Unternehmen sind alle Module in Ordnung.

Könnte das etwas mit NUMA zu tun haben? Anscheinend ist Node Interleaving auf diesem Server deaktiviert. Wird es einen Unterschied machen, es zu aktivieren (und damit NUMA auszuschalten)?

foo1:~# numactl --hardware
available: 4 nodes (0-3)
node 0 cpus: 0 1 2 3 4 5
node 0 size: 8190 MB
node 0 free: 7898 MB
node 1 cpus: 6 7 8 9 10 11
node 1 size: 12288 MB
node 1 free: 12073 MB
node 2 cpus: 18 19 20 21 22 23
node 2 size: 12288 MB
node 2 free: 12034 MB
node 3 cpus: 12 13 14 15 16 17
node 3 size: 8192 MB
node 3 free: 8032 MB
node distances:
node   0   1   2   3 
  0:  10  20  20  20 
  1:  20  10  20  20 
  2:  20  20  10  20 
  3:  20  20  20  10 

AKTUALISIEREN:

Habe NUMA (numa = off beim Linux-Boot) deaktiviert und ECC im BIOS deaktiviert. Keine Änderungen, immer noch die gleichen Zahlen wie oben.

UPDATE 2:

Hier ist das Layout des Speichers nach dmidecode:

PROC 1 DIMM 1
PROC 1 DIMM 4
PROC 1 DIMM 7
PROC 1 DIMM 10
PROC 1 DIMM 12

PROC 2 DIMM 1
PROC 2 DIMM 4
PROC 2 DIMM 7
PROC 2 DIMM 10
PROC 2 DIMM 12

Dies sind alles 4 GB Samsung-Module (Teile-Nr. M393B5270CH0-CH9)

Ich habe in den HP Dokumenten nachgesehen, wie der Speicher auf diesem Server gefüllt wird. Wenn ich das richtig verstehe, sollten die Module, die sich derzeit in DIMM 12 befinden, im DIMM 3-Steckplatz platziert werden. Kann eine solche Fehlkonfiguration die Ergebnisse erklären, die ich erhalte?

UPDATE 3:

Ich habe jetzt 2 Module entfernt, um 4x4 GB auf jeder Seite (4-4) in 1-4-7-10 zu platzieren. Leider sehe ich keinen Unterschied in den Benchmarks. Sollte der Server jetzt nicht alle vier Kanäle nutzen können? Ich habe es auch mit dem streamBenchmark mit mehreren Threads versucht und die Ergebnisse sind sehr enttäuschend. Das einzige, woran ich denken kann, ist, das Hosting-Unternehmen zu bitten, den gesamten Server zu ersetzen ...

UPDATE 4:

Ich muss etwas falsch gemacht haben, als ich streamgestern das letzte Setup (32 GB) getestet habe, denn heute sehe ich hervorragende Ergebnisse:

foo1:~# ./stream
-------------------------------------------------------------
STREAM version $Revision: 5.9 $
-------------------------------------------------------------
This system uses 8 bytes per DOUBLE PRECISION word.
-------------------------------------------------------------
Array size = 2000000, Offset = 0
Total memory required = 45.8 MB.
Each test is run 10 times, but only
the *best* time for each is used.
-------------------------------------------------------------
Number of Threads requested = 24
-------------------------------------------------------------
Printing one line per active thread....
Printing one line per active thread....
Printing one line per active thread....
Printing one line per active thread....
Printing one line per active thread....
Printing one line per active thread....
Printing one line per active thread....
Printing one line per active thread....
Printing one line per active thread....
Printing one line per active thread....
Printing one line per active thread....
Printing one line per active thread....
Printing one line per active thread....
Printing one line per active thread....
Printing one line per active thread....
Printing one line per active thread....
Printing one line per active thread....
Printing one line per active thread....
Printing one line per active thread....
Printing one line per active thread....
Printing one line per active thread....
Printing one line per active thread....
Printing one line per active thread....
Printing one line per active thread....
-------------------------------------------------------------
Your clock granularity/precision appears to be 1 microseconds.
Each test below will take on the order of 703 microseconds.
   (= 703 clock ticks)
Increase the size of the arrays if this shows that
you are not getting at least 20 clock ticks per test.
-------------------------------------------------------------
WARNING -- The above is only a rough guideline.
For best results, please be sure you know the
precision of your system timer.
-------------------------------------------------------------
Function      Rate (MB/s)   Avg time     Min time     Max time
Copy:       36873.0022       0.0009       0.0009       0.0010
Scale:      34699.5160       0.0009       0.0009       0.0010
Add:        30868.8427       0.0016       0.0016       0.0017
Triad:      25558.7904       0.0019       0.0019       0.0020
-------------------------------------------------------------
Solution Validates
-------------------------------------------------------------

(Ich habe aufgegeben, mbwda es nur im Single-Thread-Modus ausgeführt wird. Es liefert immer noch die gleichen beschissenen Ergebnisse auf diesem Server).

Das Problem müssen also die beiden letzten 4-GB-Module gewesen sein, die den Server gezwungen haben, im Einkanalmodus zu laufen, genau wie @chx unten ausgeführt hat. Jetzt bleibt nur noch die Frage, ob es möglich ist, 40 GB zu verwenden und trotzdem die volle Bandbreite zu erhalten. Kann ich 2 x 8 GB + 6 x 4 GB verwenden? Ist es wichtig, in welchem ​​Kanal ich die größeren Module platziere?


Nun - auf Ihrem Laptop läuft kein ECC, das würde das erklären. Läuft ECC auf dem Intel-Server?
Pause

Die RAM-Module im AMD-Server sind ECC-Module. Ich weiß nichts über den Intel-Server. dmidecode gibt keine Informationen zu den verwendeten Modulen. Aber könnte ECC den großen Unterschied wirklich erklären? Googeln schlägt vor, dass ECC RAM ein paar% Strafe gibt. Ich sehe hier viel mehr als das!
ntherning

Wie ist der Speicher aufgebaut? Ist es registriert?
Chris S

@ChrisS: Ich habe die Frage mit weiteren Informationen zu den Speichermodulen und dem aktuellen Layout aktualisiert.
ntherning

1
Die falsche Organisation kann Chaos verursachen, aber Ihre ist richtig. Ich bin mir wirklich nicht sicher, was hier vor sich geht, aber ich weiß, dass aktuelle Opterons aktuelle Intel-Prozessoren in verschiedenen Speicher-Benchmarks schlagen, da die Opterons 4 Kanäle haben und Intel nur 3. Es könnte etwas mit der Single-Thread-Natur los sein der mbwSoftware; obwohl ddzeigt ähnliche Ergebnisse ... Nicht sicher, aber nicht richtig.
Chris S

Antworten:


7

Sie zwingen das System, im Einkanalmodus (!) Zu arbeiten, indem Sie 5-5 Module pro CPU anstelle von 4-4 oder 8-8 verwenden. Das ist der Grund. Versuchen Sie, 1 - 1 zu entfernen und melden Sie sich zurück.

Der 6164 ist eine G34-Sockel-CPU, die Quad-Channel-Betrieb kann, wenn die Speichermodule richtig eingerichtet sind. Ihr Setup ist das schlechteste.


2
Guter Fang für die DIMM-Bevölkerung! :)
ewwhite

Die Hosting-Firma, bei der ich es vermiete, hat das Layout der Module in die Steckplätze 1-4-7-10-3 geändert, wie HP im Handbuch sagt. Kein merklicher Unterschied in meinen Tests. Ich habe sie jetzt gebeten, das letzte 4-GB-Modul auf jeder Seite zu entfernen.
ntherning

1
@chx - es scheint, als ob Sie mit dem Einkanalmodus Recht hatten. Bitte beachten Sie mein letztes Update.
ntherning

Sie benötigen vier identische Module pro Kanal, Ende der Geschichte. Und weil es sich um eine Dual-CPU handelt, benötigen Sie tatsächlich acht, um beide im Quad-Channel-Modus zum Laufen zu bringen. Also entweder 32 GB oder 64 GB. Es gibt keinen Mittelweg.
chx

2
Du hast wahrscheinlich recht. Aber der Nerd in mir kann das einfach nicht zulassen! :-) Wenn Sie nicht schon müde von mir sind, helfen Sie mir bitte, dies zu erklären: Sie haben jetzt die 4-GB-Module, die herausgenommen wurden, wieder hinzugefügt, bevor sie wieder insgesamt 40 GB und 5-5 gemacht wurden. Stream liefert wieder schlechte Ergebnisse. Aber ich habe gerade versucht, die Option numa = off boot zu entfernen, und nach einem Neustart-Stream habe ich fast die hervorragenden Ergebnisse erzielt, die ich mit 32 GB in meinem letzten Update gesehen habe.
ntherning
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.