24
Performance-Einbruch RAID
Hallo,
Ich bin gerade auf der Ursachensuche bei einem langsamen, lokalen RAID.
Server ist ein Fujitsu RX2540M1, Windows 2016, Dual-Socket CPU, 256 GB RAM, 2x Dualport 10GB NIC, PRAID EP400i, 16x1,2 TB SAS Disks.
Das System wurde mal als ESXi Host angeschafft und dient nun als Veeam Backup Server – daher die üppige Ausstattung.
Firmware und Treiber sind auf dem neuesten Stand.
Bei einem Test-Backup einer großen VM (ca 1TB) auf das lokale Repository (12 Disks im RAID6) startet das Backup mit ca. 1,1 GB/s und bricht dann nach ca. 120 GB auf 130 MB/s ein. Dies ist reproduzierbar.
Auf die eigentlichen / externen Backup-Repositories läuft das Backup konstant zwischen 600 und 800 MB/s.
Daher kann ich eigentlich alle anderen Komponenten ausschließen.
Schalte ich die RAID-Volumes von Write-Back auf Write-Trough, so startet das Backup mit nur ca. 400 MB/s und bricht dann auch wieder auf ca. 120 MB/s ein.
Bei Verwendung unter VMWare ist dies nie aufgefallen bzw. nie so getestet worden.
Bei einem ähnlichen Hardware System komme ich konstant auf ca 900MB/s schreibend. Da ist allerdings ESXi noch dazwischen.
Hat jemand eine Idee woher dieser Performance Einbruch kommen kann?
Die 1,1 GB/s sollen nicht das Ziel sein und war mehr als ich erwartet hätte. Allerdings auf die 700 MB/s sollte man hier schon kommen. Oder?
Danke und Gruß
Ich bin gerade auf der Ursachensuche bei einem langsamen, lokalen RAID.
Server ist ein Fujitsu RX2540M1, Windows 2016, Dual-Socket CPU, 256 GB RAM, 2x Dualport 10GB NIC, PRAID EP400i, 16x1,2 TB SAS Disks.
Das System wurde mal als ESXi Host angeschafft und dient nun als Veeam Backup Server – daher die üppige Ausstattung.
Firmware und Treiber sind auf dem neuesten Stand.
Bei einem Test-Backup einer großen VM (ca 1TB) auf das lokale Repository (12 Disks im RAID6) startet das Backup mit ca. 1,1 GB/s und bricht dann nach ca. 120 GB auf 130 MB/s ein. Dies ist reproduzierbar.
Auf die eigentlichen / externen Backup-Repositories läuft das Backup konstant zwischen 600 und 800 MB/s.
Daher kann ich eigentlich alle anderen Komponenten ausschließen.
Schalte ich die RAID-Volumes von Write-Back auf Write-Trough, so startet das Backup mit nur ca. 400 MB/s und bricht dann auch wieder auf ca. 120 MB/s ein.
Bei Verwendung unter VMWare ist dies nie aufgefallen bzw. nie so getestet worden.
Bei einem ähnlichen Hardware System komme ich konstant auf ca 900MB/s schreibend. Da ist allerdings ESXi noch dazwischen.
Hat jemand eine Idee woher dieser Performance Einbruch kommen kann?
Die 1,1 GB/s sollen nicht das Ziel sein und war mehr als ich erwartet hätte. Allerdings auf die 700 MB/s sollte man hier schon kommen. Oder?
Danke und Gruß
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 665415
Url: https://administrator.de/contentid/665415
Ausgedruckt am: 18.11.2024 um 21:11 Uhr
24 Kommentare
Neuester Kommentar
Moin,
der Veeam Job zeigt immer auch potentielle Bottlenecks an:
Veeam bottleneck
Wird hier ein Bottleneck genannt, würde ich diesem nachgehen.
Ansonsten kann die Rohleistung des lokalen Raid kalkuliert werden.
Raid Calculator
Gruß
Grinskeks
der Veeam Job zeigt immer auch potentielle Bottlenecks an:
Veeam bottleneck
Wird hier ein Bottleneck genannt, würde ich diesem nachgehen.
Ansonsten kann die Rohleistung des lokalen Raid kalkuliert werden.
Raid Calculator
Gruß
Grinskeks
Rein nur auf die Netz Infrastruktur gerichtet:
- Jumbo Framing auf allen aktivierten NICs UND auch am Switchport aktiviert ? (Muss bei 10G Links!)
- Passiert die Sicherung rein im Layer 2 oder über eine geroutete Verbindung ?
- Gibt es einen Medienbruch von 10G auf 1G ?
Hallo
Ich habe genau den baugleichen Server 2 x für 2 Veeam Repos hier.
Was wird letztendlich hier gesichert? Und von wo? Wie erfolgt der Zugriff zu Vmware? Per Direct SAN oder per NBD?
Läuft alles auf Jumbo Frames wie @aqui bereits gefragt hat?
Du kannst dir DiskSpd von aka.ms/diskspd laden und dann mal einen Lokalen Speedtest für Inc. Backups starten.
Siehe dazu Veeam Veeam kb2014
Gruß
Ich bin gerade auf der Ursachensuche bei einem langsamen, lokalen RAID.
Server ist ein Fujitsu RX2540M1, Windows 2016, Dual-Socket CPU, 256 GB RAM, 2x Dualport 10GB NIC, PRAID EP400i, 16x1,2 TB SAS Disks.
Das System wurde mal als ESXi Host angeschafft und dient nun als Veeam Backup Server – daher die üppige Ausstattung.
Firmware und Treiber sind auf dem neuesten Stand.
Server ist ein Fujitsu RX2540M1, Windows 2016, Dual-Socket CPU, 256 GB RAM, 2x Dualport 10GB NIC, PRAID EP400i, 16x1,2 TB SAS Disks.
Das System wurde mal als ESXi Host angeschafft und dient nun als Veeam Backup Server – daher die üppige Ausstattung.
Firmware und Treiber sind auf dem neuesten Stand.
Ich habe genau den baugleichen Server 2 x für 2 Veeam Repos hier.
Bei einem Test-Backup einer großen VM (ca 1TB) auf das lokale Repository (12 Disks im RAID6) startet das Backup mit ca. 1,1 GB/s und bricht
Was für SAS Disk sind das? 15k? 10k? 7,2k?Hat jemand eine Idee woher dieser Performance Einbruch kommen kann?
Ist dieser Server der Veeam Server selbst, oder nur ein Backup Proxy oder ein Backup Repo?Was wird letztendlich hier gesichert? Und von wo? Wie erfolgt der Zugriff zu Vmware? Per Direct SAN oder per NBD?
Läuft alles auf Jumbo Frames wie @aqui bereits gefragt hat?
Du kannst dir DiskSpd von aka.ms/diskspd laden und dann mal einen Lokalen Speedtest für Inc. Backups starten.
Siehe dazu Veeam Veeam kb2014
Active full or forward incremental
diskspd.exe -c25G -b512K -w100 -Sh -d600 D:\testfile.dat
-w100 indicates 100% writes and 0% reads. Sequential I/O is used by default.Gruß
Hallo,
Bottelneck ist laut Veeam das Target > also das RAID.
Der RAID Calculator sagt ca 366MB/s > wobei ich das nicht verstehe, da mit Cache der Stream mit 1,1 GB/s beginnt und ohne mit 400 MB/s.
Der Server ist nur mit 2x10G im Teaming angebunden. Fallback auf 1G gibt es nicht.
Auf die anderen Repositories läuft es schneller. Daher dürfte es kein Netzwerkproblem sein.
Kein Routing. Ist alles im selben VLAN.
Jumbo Frames prüfe ich noch...
Aber würde das dann so einbrechen? Hätte vermutet, dass das dann direkt problemeatisch ist und nicht erst nach über 100GB
Danke und Gruß
Bottelneck ist laut Veeam das Target > also das RAID.
Der RAID Calculator sagt ca 366MB/s > wobei ich das nicht verstehe, da mit Cache der Stream mit 1,1 GB/s beginnt und ohne mit 400 MB/s.
Der Server ist nur mit 2x10G im Teaming angebunden. Fallback auf 1G gibt es nicht.
Auf die anderen Repositories läuft es schneller. Daher dürfte es kein Netzwerkproblem sein.
Kein Routing. Ist alles im selben VLAN.
Jumbo Frames prüfe ich noch...
Aber würde das dann so einbrechen? Hätte vermutet, dass das dann direkt problemeatisch ist und nicht erst nach über 100GB
Danke und Gruß
Hallo,
10k SAS Disks
Ist der einzige Veeam Server, also mehr oder weniger Oll In One.
Die eigentlichen Repositories sind zwei Dedup Appliances
Das Full-Backup läuft hier nachts mit ca 2x 700 - 800 MB/s
Eine Windows VM mit 980GB Daten.
Per SAN Mode. Storage ist ein FullFlash Array.
Anbindung geht über dedizierte 2x10G in einem eignen iSCSI VLAN
muss ich noch prüfen
10k SAS Disks
Ist dieser Server der Veeam Server selbst, oder nur ein Backup Proxy oder ein Backup Repo?
Ist der einzige Veeam Server, also mehr oder weniger Oll In One.
Die eigentlichen Repositories sind zwei Dedup Appliances
Das Full-Backup läuft hier nachts mit ca 2x 700 - 800 MB/s
Was wird letztendlich hier gesichert? Und von wo? Wie erfolgt der Zugriff zu Vmware? Per Direct SAN oder per NBD?
Eine Windows VM mit 980GB Daten.
Per SAN Mode. Storage ist ein FullFlash Array.
Anbindung geht über dedizierte 2x10G in einem eignen iSCSI VLAN
Läuft alles auf Jumbo Frames wie @aqui bereits gefragt hat?
muss ich noch prüfen
Du kannst dir DiskSpd von aka.ms/diskspd laden und dann mal einen Lokalen Speedtest für Inc. Backups starten.
Siehe dazu Veeam Veeam kb2014
teste ich dann auch malSiehe dazu Veeam Veeam kb2014
Active full or forward incremental
> diskspd.exe -c25G -b512K -w100 -Sh -d600 D:\testfile.dat
> -w100 indicates 100% writes and 0% reads. Sequential I/O is used by default.Der Server ist nur mit 2x10G im Teaming angebunden. Fallback auf 1G gibt es nicht.
Switch dazwischen?Jumbo Frames prüfe ich noch...
Hallo,
Ich mache zunächst mit den Disk Speed Tests weiter. Aktuell läuft noch ein produktives Backup, sodass ich das abwarten muss.
Warum würdet ihr den Switch/Netzwerk als Fehlerquelle nicht ausschließen wollen?
Veeam zeigt als Bottelneck das Target an, also das lokal verbaute RAID.
Und das Backup auf die externen Netzwerk Repositories läuft ja schnell durch. Diese sind auch per 10G angebunden.
D.h. das Lesen vom Storage ist der identische Weg.
Danke und Gruß
Switch dazwischen?
Die betroffenen Systeme hängen an den gleichen beiden "Backbone" Switchen.beachte, dass du Jumbo Frames bei Windows pro Schnittstelle einstellen muss...
Danke für den Hinweis.Ich mache zunächst mit den Disk Speed Tests weiter. Aktuell läuft noch ein produktives Backup, sodass ich das abwarten muss.
Warum würdet ihr den Switch/Netzwerk als Fehlerquelle nicht ausschließen wollen?
Veeam zeigt als Bottelneck das Target an, also das lokal verbaute RAID.
Und das Backup auf die externen Netzwerk Repositories läuft ja schnell durch. Diese sind auch per 10G angebunden.
D.h. das Lesen vom Storage ist der identische Weg.
Danke und Gruß
Moin,
sicherst du die VM als VM oder sicherst du innerhalb der VM mit dem Agent?
Also zapft VEEAM den ESXi an oder hast du das Gast-OS angebunden?
Ist es ein Full oder Inkrementelles Backup?
Gruß
em-pie
sicherst du die VM als VM oder sicherst du innerhalb der VM mit dem Agent?
Also zapft VEEAM den ESXi an oder hast du das Gast-OS angebunden?
Ist es ein Full oder Inkrementelles Backup?
Gruß
em-pie
Also zapft VEEAM den ESXi an oder hast du das Gast-OS angebunden?
Er sichert per SAN Access. Somit zapft Veeam direkt das Storage an. Dies ist die schnellste Variante von Veeam.Gruß
Gruß
mea culpa,
das "SAN-Mode" hab ich überlesen -.-
Danke dir, @tech-flare
@to
hast du parallel mal den Leistungsmonitor unter Windows gestartet, um zu sehen, ob tatsächlich das RAID ausgelastst ist.
vielleicht kannst du auch am RAID selbst die Auslastung sehen - kenne die Fujitsu-Kisten nicht wirklich...
Gruß
das "SAN-Mode" hab ich überlesen -.-
Danke dir, @tech-flare
@to
hast du parallel mal den Leistungsmonitor unter Windows gestartet, um zu sehen, ob tatsächlich das RAID ausgelastst ist.
vielleicht kannst du auch am RAID selbst die Auslastung sehen - kenne die Fujitsu-Kisten nicht wirklich...
Gruß
Die betroffenen Systeme hängen an den gleichen beiden "Backbone" Switchen.
Beantwortet ja leider nicht die Fragen zum Infrastruktur Setup an sich...aber egal !Warum würdet ihr den Switch/Netzwerk als Fehlerquelle nicht ausschließen wollen?
Medienbrüche z.B. wenn deine 10G Port 10G Base T Ports sind die niemals eine feste Bandbreite negotiation sondern oft nur Bruchteile davon. 10G Base T ist KEIN verlässliches Medium um Server anzubinden ! Das ist nur DAC/Twinax oder LWL !Ebenso Problematiken der Switchhardware. Billige 10G Consumer Switches sind fast alle überbucht, schaffen also keine 10G Wirespeed und schon gar nicht bei kleinen Paketen wie sie i.d.R bei SMB/CIFS vorkommen sofern das zur Sicherung verwendet wird. Alles eben geraten...
Genau da kann es dann zu Buffer Bloats kommen im TCP die in dem geschilderten Verhalten enden.
Auch ob Jumbos durchgängig im Layer 2 definiert sind keine Aussage. Auch nicht ob das ein gerouteter Link ist oder rein Layer 2....aber egal.
OK, die Netz Infrastruktur ist ja auch nur ein Punkt von vielen. Aber diese sollte man wenigstens ausschliessen können.
Hallo,
Danke für die Unterstüzung.
Hier noch weitere Infos:
Anbindung der Systeme: je redundant 10G SFP+, OM3 LWL max 5m,
Auch nicht ob das ein gerouteter Link ist oder rein Layer 2....aber egal.
Nur das Backup auf die lokalen Platten verhält sich so.
K
Danke für die Unterstüzung.
Hier noch weitere Infos:
Zitat von @aqui:
2x Cisco Nexus 9000, 100G interconnect,Die betroffenen Systeme hängen an den gleichen beiden "Backbone" Switchen.
Beantwortet ja leider nicht die Fragen zum Infrastruktur Setup an sich...aber egal !Anbindung der Systeme: je redundant 10G SFP+, OM3 LWL max 5m,
Genau da kann es dann zu Buffer Bloats kommen im TCP die in dem geschilderten Verhalten enden.
Würde dies nicht schon nach ein paar Sekunden auftreten und nicht erst nach Minuten und über 100 GBAuch ob Jumbos durchgängig im Layer 2 definiert sind keine Aussage.
richtig, dass muss ich noch prüfenAuch nicht ob das ein gerouteter Link ist oder rein Layer 2....aber egal.
Kein Routing. Ist alles im selben VLAN.
OK, die Netz Infrastruktur ist ja auch nur ein Punkt von vielen. Aber diese sollte man wenigstens ausschliessen können.
Würde ich ja, durch das Ausschlussprinzip.Nur das Backup auf die lokalen Platten verhält sich so.
K
Hallo,
Write IO
thread | bytes | I/Os | MiB/s | I/O per s | file
0 | 31879331840 | 60805 | 50.67 | 101.34 | e:\test\testfile.dat (25GiB)
total: 31879331840 | 60805 | 50.67 | 101.34
Hast du Referenzwerte?
Danke und Gruß
Zitat von @ElmerAcmeee:
Ergebnis:Du kannst dir DiskSpd von aka.ms/diskspd laden und dann mal einen Lokalen Speedtest für Inc. Backups starten.
Siehe dazu Veeam Veeam kb2014
Siehe dazu Veeam Veeam kb2014
Active full or forward incremental
>> diskspd.exe -c25G -b512K -w100 -Sh -d600 D:\testfile.dat
>> -w100 indicates 100% writes and 0% reads. Sequential I/O is used by default.Write IO
thread | bytes | I/Os | MiB/s | I/O per s | file
0 | 31879331840 | 60805 | 50.67 | 101.34 | e:\test\testfile.dat (25GiB)
total: 31879331840 | 60805 | 50.67 | 101.34
Hast du Referenzwerte?
Danke und Gruß
Der RAID Calculator sagt ca. 366MB/s > wobei ich das nicht verstehe, da mit Cache der Stream mit 1,1 GB/s beginnt und ohne mit 400 MB/s.
Das kommt daher, dass die Performance immer eine Momentan-Aufnahme über den bisherigen zeitlichen Verlauf ist. Am Anfang ist der cache evtl. prall mit nutzbaren Daten gefüllt und es findet bereits vor der zeitlichen Messung eine Vorbereitung der Daten statt, daher gibt es zum Start einen vermeintlich relativ hohen Durchsatz.
Nur über den kompletten Zeitraum lässt sich der tatsächliche durchschnittliche Durchsatz sinnvoll interpretieren.
Der Einbruch auf 130MB/s ist schon irgendwie verdächtig nahe 1 Gbit/s.
Wie geht's dem Raid denn sonst so? Sind die Platten sind noch alle frisch oder gibt es Anzeichen drohender Defekte?
Man könnte beispielsweise über storcli die Smart-Attribute auslesen.
Falls die Platten ok sind: Lässt sich das Verhalten auch mit anderen VMs nachstellen? Tritt das Verhalten immer nach der gleichen übertragenen Datenmenge ein?
Gruß
Grinskeks
Zitat von @ElmerAcmeee:
Ergebnis:
Write IO
thread | bytes | I/Os | MiB/s | I/O per s | file
0 | 31879331840 | 60805 | 50.67 | 101.34 | e:\test\testfile.dat (25GiB)
total: 31879331840 | 60805 | 50.67 | 101.34
Hast du Referenzwerte?
Jetzt nicht im Kopf, aber für SAS Platten finde ich den Wert jetzt nicht wirklich gut.Ergebnis:
Write IO
thread | bytes | I/Os | MiB/s | I/O per s | file
0 | 31879331840 | 60805 | 50.67 | 101.34 | e:\test\testfile.dat (25GiB)
total: 31879331840 | 60805 | 50.67 | 101.34
Hast du Referenzwerte?
Ich lasse morgen mal einen Test auf einem Raid 60 (16 Bay) und Raid 6 SAS 7,2k laufen und übermittel dir die Daten.
Moin,
130MB/s ist deutlich über 1Gbit/s wenn man den ganzen Overhead mitbetrachtet.
DANKE!
Zitat von @Grinskeks:
Nur über den kompletten Zeitraum lässt sich der tatsächliche durchschnittliche Durchsatz sinnvoll interpretieren.
Der Einbruch auf 130MB/s ist schon irgendwie verdächtig nahe 1 Gbit/s.
Laut Netzwerk- und Festplattenauslastung im Performancemonitor fängt der wirklich mit 1GB/s an.Nur über den kompletten Zeitraum lässt sich der tatsächliche durchschnittliche Durchsatz sinnvoll interpretieren.
Der Einbruch auf 130MB/s ist schon irgendwie verdächtig nahe 1 Gbit/s.
130MB/s ist deutlich über 1Gbit/s wenn man den ganzen Overhead mitbetrachtet.
Wie geht's dem Raid denn sonst so? Sind die Platten sind noch alle frisch oder gibt es Anzeichen drohender Defekte?
Laut iRMC ist alles superMan könnte beispielsweise über storcli die Smart-Attribute auslesen.
StorCli kenn ich noch nicht. Mache mich dazu dann heute mal schlau.Falls die Platten ok sind: Lässt sich das Verhalten auch mit anderen VMs nachstellen? Tritt das Verhalten immer nach der gleichen übertragenen Datenmenge ein?
Teste ich heute nochmals und versuche den genauen Zeitpunkt zu ermittelnDANKE!
Hallo,
ein Update von meiner Seite:
Einige Zahlen habe ich wohl sehr falsch interpretiert und muss daher auch einige Aussagen zurück nehmen.
SORRY dafür!
Die 1GB/s kommen nach neuester Erkenntnis daher, dass sowhl in den RAM als auch auf die Platte geschrieben wird.
Veeam zeigt als Druchsatz den Netzwerkdurchsatz an.
Im Windows Resource Monitor ist mir irgendwann aufgefallen, dass die Werte von Netzwerk und Disk weit auseinander driften aber sich auch wieder annähern.
Z.B.
Netzwerkdurchsatz = 1GB/s wärend Disk schreiben = 200 MB/s
oder:
Netzwerkdurchsatz = 10 MB/s wärend Disk schreiben = 190 MB/s
Wärend dieser Werte steigt und fällt der "Modified" RAM.
Da die Kiste 256 GB RAM hat, wurde wohl die hälfte als Puffer genutzt. Daher auch die 1.1GB/s am Anfang, also mit maximaler Auslastung der NIC zu 90% in den RAM geschrieben.
Damit ergibt sich dann die Schreibperformance aus der Laufzeit und Datenmenge.
In unserem Fall ca 250MB/s, was ich noch als deutlich zu langsam erachte...
Danke und Gruß
ein Update von meiner Seite:
Einige Zahlen habe ich wohl sehr falsch interpretiert und muss daher auch einige Aussagen zurück nehmen.
SORRY dafür!
Die 1GB/s kommen nach neuester Erkenntnis daher, dass sowhl in den RAM als auch auf die Platte geschrieben wird.
Veeam zeigt als Druchsatz den Netzwerkdurchsatz an.
Im Windows Resource Monitor ist mir irgendwann aufgefallen, dass die Werte von Netzwerk und Disk weit auseinander driften aber sich auch wieder annähern.
Z.B.
Netzwerkdurchsatz = 1GB/s wärend Disk schreiben = 200 MB/s
oder:
Netzwerkdurchsatz = 10 MB/s wärend Disk schreiben = 190 MB/s
Wärend dieser Werte steigt und fällt der "Modified" RAM.
Da die Kiste 256 GB RAM hat, wurde wohl die hälfte als Puffer genutzt. Daher auch die 1.1GB/s am Anfang, also mit maximaler Auslastung der NIC zu 90% in den RAM geschrieben.
Damit ergibt sich dann die Schreibperformance aus der Laufzeit und Datenmenge.
In unserem Fall ca 250MB/s, was ich noch als deutlich zu langsam erachte...
Danke und Gruß
Hallo
Durch das letzte Firmware Update des RAID Controllers war wohl für das Volume der Diskcache disabled.
Nun komme ich auf diese Werte:
Write IO
thread | bytes | I/Os | MiB/s | I/O per s | file
0 | 56803459072 | 108344 | 90.29 | 180.57 | e:\test\testfile.dat (25GiB)
total: 56803459072 | 108344 | 90.29 | 180.57
Unter Veeam erreiche ich damit laut Resource Monitor nun 250MB/s
Ich lasse morgen mal einen Test auf einem Raid 60 (16 Bay) und Raid 6 SAS 7,2k laufen und übermittel dir die Daten.
Durch das letzte Firmware Update des RAID Controllers war wohl für das Volume der Diskcache disabled.
Nun komme ich auf diese Werte:
Write IO
thread | bytes | I/Os | MiB/s | I/O per s | file
0 | 56803459072 | 108344 | 90.29 | 180.57 | e:\test\testfile.dat (25GiB)
total: 56803459072 | 108344 | 90.29 | 180.57
Unter Veeam erreiche ich damit laut Resource Monitor nun 250MB/s
Da die Kiste 256 GB RAM hat, wurde wohl die hälfte als Puffer genutzt. Daher auch die 1.1GB/s am Anfang, also mit maximaler Auslastung der NIC zu 90% in den RAM geschrieben.
Das ergibt Sinn. Der eine Veeam Proxy hat hier 64GB Ram. Ich beobachte das mal.Zitat von @ElmerAcmeee:
Hallo
Durch das letzte Firmware Update des RAID Controllers war wohl für das Volume der Diskcache disabled.
Nun komme ich auf diese Werte:
Write IO
thread | bytes | I/Os | MiB/s | I/O per s | file
0 | 56803459072 | 108344 | 90.29 | 180.57 | e:\test\testfile.dat (25GiB)
total: 56803459072 | 108344 | 90.29 | 180.57
Unter Veeam erreiche ich damit laut Resource Monitor nun 250MB/s
Hallo
Ich lasse morgen mal einen Test auf einem Raid 60 (16 Bay) und Raid 6 SAS 7,2k laufen und übermittel dir die Daten.
Durch das letzte Firmware Update des RAID Controllers war wohl für das Volume der Diskcache disabled.
Nun komme ich auf diese Werte:
Write IO
thread | bytes | I/Os | MiB/s | I/O per s | file
0 | 56803459072 | 108344 | 90.29 | 180.57 | e:\test\testfile.dat (25GiB)
total: 56803459072 | 108344 | 90.29 | 180.57
Unter Veeam erreiche ich damit laut Resource Monitor nun 250MB/s
So sieht es bei mir auf dem RX2540M1 aus.
Raid60, 7,2k SATA HDD
Total IO
thread | bytes | I/Os | MiB/s | I/O per s | file
0 | 243658129408 | 464741 | 387.28 | 774.57 | Q:\testfile.dat (25GiB)
total: 243658129408 | 464741 | 387.28 | 774.57
Hallo,
Ich muss gestehen, von RAID60 habe ich bislang noch nie gehört...
Mein erster Google-Treffer sagt: Nachteil: sehr langsame Schreibgeschwindigkeit
hmmm, und trotzdem schneller als mein SAS 10k Volume.
Ich glaube ich werde aus dem RAID6 mal ein RAID10 machen, oder was der Controller sonst noch so hergibt.
Trotzdem werde ich das Gefühl nicht los, dass es eigentlich jetzt schon deutlich schneller sein sollte...
Ich werde berichten..
Danke und Gruß
Zitat von @tech-flare:
So sieht es bei mir auf dem RX2540M1 aus.
Raid60, 7,2k SATA HDD
Total IO
thread | bytes | I/Os | MiB/s | I/O per s | file
0 | 243658129408 | 464741 | 387.28 | 774.57 | Q:\testfile.dat (25GiB)
total: 243658129408 | 464741 | 387.28 | 774.57
So sieht es bei mir auf dem RX2540M1 aus.
Raid60, 7,2k SATA HDD
Total IO
thread | bytes | I/Os | MiB/s | I/O per s | file
0 | 243658129408 | 464741 | 387.28 | 774.57 | Q:\testfile.dat (25GiB)
total: 243658129408 | 464741 | 387.28 | 774.57
Ich muss gestehen, von RAID60 habe ich bislang noch nie gehört...
Mein erster Google-Treffer sagt: Nachteil: sehr langsame Schreibgeschwindigkeit
hmmm, und trotzdem schneller als mein SAS 10k Volume.
Ich glaube ich werde aus dem RAID6 mal ein RAID10 machen, oder was der Controller sonst noch so hergibt.
Trotzdem werde ich das Gefühl nicht los, dass es eigentlich jetzt schon deutlich schneller sein sollte...
Ich werde berichten..
Danke und Gruß
Zitat von @ElmerAcmeee:
Hallo,
Ich muss gestehen, von RAID60 habe ich bislang noch nie gehört...
Mein erster Google-Treffer sagt: Nachteil: sehr langsame Schreibgeschwindigkeit
Raid 6 ist eine Kombination aus Raid 6+0.Hallo,
Zitat von @tech-flare:
So sieht es bei mir auf dem RX2540M1 aus.
Raid60, 7,2k SATA HDD
Total IO
thread | bytes | I/Os | MiB/s | I/O per s | file
0 | 243658129408 | 464741 | 387.28 | 774.57 | Q:\testfile.dat (25GiB)
total: 243658129408 | 464741 | 387.28 | 774.57
So sieht es bei mir auf dem RX2540M1 aus.
Raid60, 7,2k SATA HDD
Total IO
thread | bytes | I/Os | MiB/s | I/O per s | file
0 | 243658129408 | 464741 | 387.28 | 774.57 | Q:\testfile.dat (25GiB)
total: 243658129408 | 464741 | 387.28 | 774.57
Ich muss gestehen, von RAID60 habe ich bislang noch nie gehört...
Mein erster Google-Treffer sagt: Nachteil: sehr langsame Schreibgeschwindigkeit
Somit schneller als Raid6 ;) Lohnt sich aber erst bei einer bestimmten Anzahl an Platten.
hmmm, und trotzdem schneller als mein SAS 10k Volume.
Ich glaube ich werde aus dem RAID6 mal ein RAID10 machen, oder was der Controller sonst noch so hergibt.
Raid 10 ist die schnellste Möglichkeit. Jedoch verlierst du da die Hälfte an Kapazität..Ich glaube ich werde aus dem RAID6 mal ein RAID10 machen, oder was der Controller sonst noch so hergibt.
Trotzdem werde ich das Gefühl nicht los, dass es eigentlich jetzt schon deutlich schneller sein sollte...
Ja. Es ist definitiv zu langsam.Trotzdem werde ich das Gefühl nicht los, dass es eigentlich jetzt schon deutlich schneller sein sollte...
Wenn das Raid neu gemacht werden kann, schau dir doch mal die Stripe Size an und optimiere diese für den konkreten Anwendungsfall.
Dein Veeam hat beispielsweise 512 KB Blöcke mit standard compression ( 1 MB local target / Faktor 2 Kompression ca.)
Je näher deine Stripe Size an der Veeam Größe ist, desto weniger Blöcke musst du schreiben - im Idealfall ohne Verlust
Im Filesystem kann man die Block Size dann auch entsprechend erhöhen.
Beispiel:
Stripe Size 64 KB , Veeam Block mit 512 KB = 8 I/O um den Block zu schreiben.
Stripe Size 128 KB , Veeam Block mit 512 KB = 4 I/O um den Block zu schreiben.
Gruß
Grinskeks
Hallo,
so, RAID10 wurde neu erstellt mit 1MB Stripe Size und allen Cache Optionen aktiviert.
Neues DiskSpeed Ergenis:
Write IO
thread | bytes | I/Os | MiB/s | I/O per s | file
0 | 496465608704 | 946933 | 789.10 | 1578.20 | e:\perftest\testfile.dat (25GiB)
total: 496465608704 | 946933 | 789.10 | 1578.20
Das sieht doch mal recht ordentlich aus.
Alledings verhält sich Veeam nun anders.
Anstelle direkt, wie gestern, mit den 1GB/s los zu laufen und einen teil in den RAM zu schreiben, geht es jetzt direkt auf die Platte mit ca 380MB/s.
Ursache davon ist nun, dass das Storage zu langsam wäre. Bottleneck 99% Source. ???
Aber das ist nun wieder eine andere Baustelle...
Das eigentliche Problem habe ich nun Dank eurer Hilfe beheben können.
Somit, besten Dank!
so, RAID10 wurde neu erstellt mit 1MB Stripe Size und allen Cache Optionen aktiviert.
Neues DiskSpeed Ergenis:
Write IO
thread | bytes | I/Os | MiB/s | I/O per s | file
0 | 496465608704 | 946933 | 789.10 | 1578.20 | e:\perftest\testfile.dat (25GiB)
total: 496465608704 | 946933 | 789.10 | 1578.20
Das sieht doch mal recht ordentlich aus.
Alledings verhält sich Veeam nun anders.
Anstelle direkt, wie gestern, mit den 1GB/s los zu laufen und einen teil in den RAM zu schreiben, geht es jetzt direkt auf die Platte mit ca 380MB/s.
Ursache davon ist nun, dass das Storage zu langsam wäre. Bottleneck 99% Source. ???
Aber das ist nun wieder eine andere Baustelle...
Das eigentliche Problem habe ich nun Dank eurer Hilfe beheben können.
Somit, besten Dank!
