Hetzner Server langsame SSD

ThomasChr

Member
@andreas0
Ich hab nochmal nachgeprüft (diesmal mit strace).
Wir verlieren tatsächlich sehrviel Zeit mit read - ABER auch das write braucht länger (ca. Faktor 4).
Problem ist nur, der große Unterschied den du misst und damit auch die Zeitverzögerung die kommt vom read - selbst wenn der write mit den Zufallszahlen auch ein gutes Stück langsamer ist.
Ich bin schon so oft bei Benchmarks reingefallen, und auch so oft beim interpretieren all der schönen Daten die man hier hat.
Vorallem strace hat natürlich einen erheblichen Overhead der das Bild auch wieder verschieben kann. Und das Profiling misst natürlich eher on-cpu als off-cpu time, erwischt also eine CPU die gerade idle ist evtl. garnicht (denn beim I/O macht die CPU ja nichts mehr).
Ich bin mir recht sicher dass es trotzdem beweist dass das lesen von /dev/urandom hier hauptsächlich bremsend wirkt.

/dev/urandom:
Code:
     0.001207 read(0, "\324W\230\17\302\256\236\256\373\205Z\34\253y\36\237\235\365\5r;\347\377\332\251\21\4c\"\342\356\236"..., 1048576) = 1048576
     0.079115 write(1, "\324W\230\17\302\256\236\256\373\205Z\34\253y\36\237\235\365\5r;\347\377\332\251\21\4c\"\342\356\236"..., 1048576) = 1048576
     0.001449 read(0, "e\205\261\3101n\215\36\nILRd~\32\362\376\20\265i\373\333\314\37\20\301[\215\272\322\202g"..., 1048576) = 1048576
     0.077722 write(1, "e\205\261\3101n\215\36\nILRd~\32\362\376\20\265i\373\333\314\37\20\301[\215\272\322\202g"..., 1048576) = 1048576
     0.001092 read(0, "%\346\304\245\205\264\235*\335\242,\201\212\321\354\224u\247\7}b\256\324\301J\326\255x\356\221\203\20"..., 1048576) = 1048576
     0.078041 write(1, "%\346\304\245\205\264\235*\335\242,\201\212\321\354\224u\247\7}b\256\324\301J\326\255x\356\221\203\20"..., 1048576) = 1048576
     0.001092 read(0, "d3\354k{p\326$'4\n\33P\34\330\376\202i\214\1}\36~\7\0203:\355M\247\375t"..., 1048576) = 1048576
     0.086590 write(1, "d3\354k{p\326$'4\n\33P\34\330\376\202i\214\1}\36~\7\0203:\355M\247\375t"..., 1048576) = 1048576
Code:
1048576000 bytes (1,0 GB, 1000 MiB) copied, 81,1233 s, 12,9 MB/s
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 99.93   78.949348       78713      1003           read
  0.07    0.052598          52      1003           write
  0.00    0.000000           0        10         3 open
  0.00    0.000000           0        10           close
  0.00    0.000000           0         5           fstat
  0.00    0.000000           0         1           lseek
  0.00    0.000000           0        11           mmap
  0.00    0.000000           0         4           mprotect
  0.00    0.000000           0         1           munmap
  0.00    0.000000           0         3           brk
  0.00    0.000000           0         3           rt_sigaction
  0.00    0.000000           0         3         3 access
  0.00    0.000000           0         2           dup2
  0.00    0.000000           0         1           execve
  0.00    0.000000           0         1           arch_prctl
  0.00    0.000000           0         2           clock_gettime
------ ----------- ----------- --------- --------- ----------------
100.00   79.001946                  2063         6 total
-> read braucht 78713 Mikrosekunden pro Call
-> Insgesamt 78.949348 Sekunden read bei 1003 Calls
-> Write braucht 52 Mikrosekunden pro Call
-> Insgesamt 0.052598 Write bei 1003 Calls





/dev/zero:
Code:
     0.001095 read(0, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576) = 1048576
     0.000145 write(1, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576) = 1048576
     0.001492 read(0, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576) = 1048576
     0.000161 write(1, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576) = 1048576
     0.000997 read(0, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576) = 1048576
     0.000153 write(1, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576) = 1048576
     0.001048 read(0, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576) = 1048576
     0.000139 write(1, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576) = 1048576
Code:
1048576000 bytes (1,0 GB, 1000 MiB) copied, 1,05237 s, 996 MB/s
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 85.43    0.012319          12      1003           write
 14.57    0.002101           2      1003           read
  0.00    0.000000           0        10         3 open
  0.00    0.000000           0        10           close
  0.00    0.000000           0         5           fstat
  0.00    0.000000           0         1           lseek
  0.00    0.000000           0        11           mmap
  0.00    0.000000           0         4           mprotect
  0.00    0.000000           0         1           munmap
  0.00    0.000000           0         3           brk
  0.00    0.000000           0         3           rt_sigaction
  0.00    0.000000           0         3         3 access
  0.00    0.000000           0         2           dup2
  0.00    0.000000           0         1           execve
  0.00    0.000000           0         1           arch_prctl
  0.00    0.000000           0         2           clock_gettime
------ ----------- ----------- --------- --------- ----------------
100.00    0.014420                  2063         6 total
-> read braucht 2 Mikrosekunden per Call
-> Insgesamt 0.003538 Sekunden read bei 1003 Calls
-> Write braucht 12 Mikrosekunden per Call
-> Insgesamt 0.031711 Sekunden write bei 1003 Calls

Vermutung warum dein dedi-Server hier schneller ist:
Hardwarezufallsgenerator.
Auf dem Dedi einer für den Server, beim vServer nur einer für viele Server.
Ich glaub fast alle neueren Prozessoren haben Zufallsgeneratoren in Hardware die der Linux Kernel nutzt.
 
Last edited by a moderator:
A

andreas0

Guest
Vermutung warum dein dedi-Server hier schneller ist:
Hardwarezufallsgenerator.
Auf dem Dedi einer für den Server, beim vServer nur einer für viele Server.
Ich glaub fast alle neueren Prozessoren haben Zufallsgeneratoren in Hardware die der Linux Kernel nutzt.


Das die CPU zum Generieren der Zufallszahlen Zeit benötigt, ist mir bewußt.

Von daher habe ich auch mal auf einer meiner virtuellen Maschinen (KVM) auf diesem dedizierten Server mit 4 SSDs im RAID 10 Verbund folgende Tests durchgeführt:

Bei den folgenden Tests wird auch der Controller-Cache umgangen:

Code:
dd if=/dev/urandom of=testfile bs=1M count=1024 [B]oflag=direct[/B]
1073741824 Bytes (1,1 GB) kopiert, 6,30379 s, 170 MB/s

dd if=/dev/urandom of=testfile1 bs=1M count=1024
1073741824 Bytes (1,1 GB) kopiert, 5,86621 s, 183 MB/s

dd if=/dev/urandom of=testfile2 bs=1M count=1024 [B]oflag=direct[/B]
1073741824 Bytes (1,1 GB) kopiert, 5,84164 s, 184 MB/s


Bei folgenden Tests sieht man sehr gut, wie sich die Schreibleistung auch bei größeren Dateien nicht wirklich groß verändert:

Code:
dd if=/dev/zero bs=1M count=10000 of=testfile3
10394533888 Bytes (10 GB) kopiert, 6,056189 s, 1,7 GB/s

dd if=/dev/zero bs=1M count=10000 of=testfile4
9855565824 Bytes (9,9 GB) kopiert, 6,009310 s, 1,6 GB/s


Bei diesem Test hatte die Schreibleistung mit ca. 1,7 GB/s begonnen und endete mit 1,1 GB/s.

Code:
dd if=/dev/zero bs=1M count=30000 of=testfile5
31183601664 Bytes ([B]31 GB[/B]) kopiert, 28,198077 s, 1,1 GB/s


Bei folgendem Test hatte die Schreibleistung mit ca. 900 MB/s begonnen und endete mit 830 MB/s.

Code:
dd if=/dev/zero bs=1M count=30000 of=testfile6 [B]oflag=direct[/B]
30746345472 Bytes ([B]31 GB[/B]) kopiert, 37,022610 s, 830 MB/s
 

ThomasChr

Member
Und was sagt die CPU während der Tests? System Mode CPU Time oder iowait?
(mpstat -P ALL 1)
 
Last edited by a moderator:

Joe User

Zentrum der Macht
Fun fact: Wie oft schreibt ein 0815-Rootserver der SSF-Klientel Files mit Grössen von 1GB oder mehr?

Eure "Benchmarks" sind schlicht untauglich...

BTW: oflag=direct umgeht lediglich den Festplattencache und nicht den Cache von RAID-Controllern.
BTW2: Das Filesystem und das gegebenenfalls aktive Journal spielt auch eine Rolle.
BTW3: Beim Software-RAID spielt auch das Metadaten-Format eine Rolle.
 
A

andreas0

Guest
Und was sagt die CPU während der Tests? System Mode CPU Time oder iowait?
(mpstat -P ALL 1)


Meine VM auf dem dedizierten Server:

Code:
dd if=/dev/urandom of=testfile1 bs=1M count=1024 oflag=direct
1073741824 Bytes (1,1 GB) kopiert, 5,84444 s, 184 MB/s

Durchschn.:  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
Durchschn.:  all    0,09    0,00    0,62    0,00    0,00    0,00    0,00    0,00    0,00   96,15
Durchschn.:    0    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00  100,00
[B]Durchschn.:    1    0,03    0,00    4,92    0,00    0,00    0,00    0,00    0,00    0,00   95,06[/B]
Durchschn.:    2    0,03    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00   99,97
Durchschn.:    3    0,33    0,00    0,05    0,00    0,00    0,00    0,00    0,00    0,00   99,62
Durchschn.:    4    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00  100,00
Durchschn.:    5    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00  100,00
Durchschn.:    6    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00  100,00
Durchschn.:    7    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00  100,00


VM RS 8000 SSD G7 SE bei Netcup:

Code:
dd if=/dev/urandom bs=1M count=1024 of=testfile oflag=direct
1019215872 Bytes (1,1 GB) kopiert, 11,112309 s, 91,7 MB/s

Durchschn.:  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
Durchschn.:  all    0,01    0,00    3,73    0,71    0,00    0,01    0,02    0,00    0,00   95,52
Durchschn.:    0    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00  100,00
Durchschn.:    1    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00  100,00
Durchschn.:    2    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00  100,00
Durchschn.:    3    0,00    0,00    0,00    0,08    0,00    0,00    0,08    0,00    0,00   99,85
Durchschn.:    4    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00  100,00
[B]Durchschn.:    5    0,00    0,00   44,93    8,58    0,00    0,15    0,08    0,00    0,00   46,25[/B]
Durchschn.:    6    0,00    0,00    0,08    0,00    0,00    0,00    0,00    0,00    0,00   99,92
Durchschn.:    7    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00  100,00
Durchschn.:    8    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00  100,00
Durchschn.:    9    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00  100,00
Durchschn.:   10    0,00    0,00    0,00    0,00    0,00    0,00    0,08    0,00    0,00   99,92
Durchschn.:   11    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00  100,00


VM mit der Produktbezeichnung "Virtual Server Cloud XL" bei 1&1:

Code:
dd status=progress if=/dev/urandom of=testfile bs=1M count=1024 oflag=direct
1073741824 Bytes (1,1 GB) kopiert, 15,6879 s, 68,4 MB/s

10:53:00     CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
10:53:01     all    1,00    0,00   22,00   28,00    0,00    0,00    0,00    0,00    0,00   49,00
[B]10:53:01       0    1,00    0,00   43,00   56,00    0,00    0,00    0,00    0,00    0,00    0,00[/B]
10:53:01       1    2,02    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00   97,98


Schaut man sich das Ergebnis von der VM "Virtual Server Cloud XL" bei 1&1 an, so gebe ich dir Recht. Denn hier wird der erste Kern zu 100 % belastet und kann damit die Schreibgeschwindigkeit ausbremsen. Von daher kann man die Schreibleistung durch das Generieren von Zufallszahlen leider nur bedingt auf einer VM messen.
 
Last edited by a moderator:

ThomasChr

Member
Fast keine Iowait...
Der Dedi hat trotzdem wenig System Mode CPU, vermutlich weil er leichter Zufall bekommt. Der netcup kämpft ziemlich um seinen Zufall.
Wie ists bei /dev/zero?
 
A

andreas0

Guest
Fast keine Iowait...
Der Dedi hat trotzdem wenig System Mode CPU, vermutlich weil er leichter Zufall bekommt. Der netcup kämpft ziemlich um seinen Zufall.
Wie ists bei /dev/zero?


Meine VM auf dem dedizierten Server:

Code:
dd if=/dev/zero of=testfile bs=1M count=1024
1073741824 Bytes (1,1 GB) kopiert, 0,518492 s, 2,1 GB/s

Durchschn.:  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
Durchschn.:  all    0,04    0,00    1,86    0,00    0,00    0,00    0,00    0,00    0,00   98,11
Durchschn.:    0    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00  100,00
Durchschn.:    1    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00  100,00
Durchschn.:    2    0,00    0,00    0,14    0,00    0,00    0,00    0,00    0,00    0,00   99,86
[B]Durchschn.:    3    0,00    0,00    7,30    0,00    0,00    0,00    0,00    0,00    0,00   92,70[/B]
Durchschn.:    4    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00  100,00
Durchschn.:    5    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00  100,00
Durchschn.:    6    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00  100,00
Durchschn.:    7    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00  100,00


VM RS 8000 SSD G7 SE bei Netcup:

Code:
dd if=/dev/zero of=testfile bs=1M count=1024
1073741824 Bytes (1,1 GB) kopiert, 2,23234 s, 481 MB/s

22:55:58     CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
22:55:59     all    0,00    0,00    1,00    6,09    0,00    0,25    0,00    0,00    0,00   92,66
22:55:59       0    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00  100,00
22:55:59       1    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00  100,00
22:55:59       2    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00  100,00
22:55:59       3    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00  100,00
22:55:59       4    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00  100,00
22:55:59       5    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00  100,00
22:55:59       6    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00  100,00
22:55:59       7    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00  100,00
[B]22:55:59       8    0,99    0,00   11,88   72,28    0,00    2,97    0,00    0,00    0,00   11,88[/B]
22:55:59       9    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00  100,00
22:55:59      10    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00  100,00
22:55:59      11    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00  100,00


VM mit der Produktbezeichnung "Virtual Server Cloud XL" bei 1&1:

Code:
dd if=/dev/zero of=testfile1 bs=1M count=1024
1073741824 Bytes (1,1 GB) kopiert, 1,14445 s, 938 MB/s

10:38:54     CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
10:38:55     all    0,51    0,00   32,32   51,01    0,00    0,51    0,00    0,00    0,00   15,66
10:38:55       0    0,00    0,00   38,78   36,73    0,00    0,00    0,00    0,00    0,00   24,49
[B]10:38:55       1    0,00    0,00   27,27   65,66    0,00    0,00    0,00    0,00    0,00    7,07[/B]
 
Last edited by a moderator:

Vengance

Member
Teste die Platten mal einzeln mit hdparm; wenn eine SSD langsam stirbt, reißt sie den RAID-Verbund runter. Kommt insbesondere bei Desktop-SSDs häufiger vor, wobei ich die Produktpalette von Hetzner jetzt nicht mehr so genau kenne, also nicht weiß, ob in deinem Server nicht doch schon Datacenter-SSDs rennen.

Es sind Micron M600 SSDs, also Consumer Modelle.


Zwar nur Read, sieht aber denke ich dennoch soweit ok aus:
Code:
root@pve ~ #  hdparm -Tt /dev/sda

/dev/sda:
 Timing cached reads:   30394 MB in  2.00 seconds = 15213.22 MB/sec
 Timing buffered disk reads: 1310 MB in  3.00 seconds = 436.21 MB/sec
root@pve ~ # hdparm -Tt /dev/sdb

/dev/sdb:
 Timing cached reads:   30606 MB in  2.00 seconds = 15320.33 MB/sec
 Timing buffered disk reads: 1136 MB in  3.00 seconds = 378.12 MB/sec
 
A

andreas0

Guest
@Vengance
Bleiben denn jetzt bei beiden SSD-Laufwerken die Schreibgeschwindigkeiten stabil bei > 300 MB/s?
 

Vengance

Member
Nein, die Schreibrate ist wieder stark schwankend und auch zu niedrig.
Das System nutzt LVM, kann das ggfls. einen Einfluss darauf haben?

Code:
root@pve ~ # dd if=/dev/zero of=aadtesset bs=1G count=1 oflag=direct
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 5.53279 s, 194 MB/s
root@pve ~ # dd if=/dev/zero of=adet bs=1G count=1 oflag=direct
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 4.14484 s, 259 MB/s
root@pve ~ # dd if=/dev/zero of=iotestfile bs=1G count=1 oflag=direct
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 5.7929 s, 185 MB/s
root@pve ~ # dd if=/dev/zero of=iotestfile2 bs=1G count=1 oflag=direct
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 5.58081 s, 192 MB/s
 
A

andreas0

Guest
Nein, die Schreibrate ist wieder stark schwankend und auch zu niedrig.
Das System nutzt LVM, kann das ggfls. einen Einfluss darauf haben?

Normal nicht.

Ich selber bevorzuge zum ausgiebigen Testen solcher SSDs ganz gern ext4 alleine.
Hierzu nutze ich dann auch ganz gern das Rettungssystem vom Provider und hänge dann die Problemlaufwerke per ext4 ein.
 

Vengance

Member
Ohne Datenverlust kann ich das Laufwerk ja dann vermutlich nicht einfach als ext4 einhängen, da das ja ein LVM2 Member ist, oder verstehe ich da was falsch?
 
A

andreas0

Guest
Ohne Datenverlust kann ich das Laufwerk ja dann vermutlich nicht einfach als ext4 einhängen, da das ja ein LVM2 Member ist, oder verstehe ich da was falsch?

Mit LVM / LVM2 habe ich selber keine Erfahrung.

Aber ich glaube, dass du dennoch die jeweilige SSD als ext4 im Rettungssystem mounten kannst.
Du solltest danach dann aber nicht direkt auf der SSD (dev/sda) schreiben, sondern besser nur in einer Datei.

Probiere es einfach mal aus. Denn, solange du nur in einer Datei reinschreibst, sollten auf der jeweiligen SSD keine Daten verloren gehen.

Soeben habe ich auch mal in meinem Kundenbereich bei Hetzner geschaut.
Unter dem Kartenreiter des dedizierten Servers gibt es auch noch ein Kartenreiter Backup mit einem FTP-Speicherplatz von 100 GB.

Zwar ist die Gefahr eher gering, aber dennoch wäre es eventuell gut, wenn du zuvor, bevor du denn mit den intensiveren Tests der jeweiligen SSD beginnen solltest, deine wichtigsten Daten auf dem FTP-Speicher sicherst.
 
Last edited by a moderator:

ThomasChr

Member
Du hast sicherlich ein aktuelles Backup, oder?
Wenn nein: Jetzt ist der Zeitpunkt ein funktionierendes Backupkonzept zu erarbeiten!
 

Vengance

Member
Ein Backup ist natürlich vorhanden, das System ist aber momentan ohnehin noch leer.

Die SSD (bzw. das SW RAID) lässt sich scheinbar nicht Mounten, ich bekomme die Meldung, dass sie/ es ein Member des LVM2 ist.
 

Vengance

Member
Nun ist die IO Performance mal wieder besser.. Hält aber wahrscheinlich wieder nur kurz an.

Code:
root@pve ~ # dd if=/dev/zero of=iotestfile2 bs=1G count=1 oflag=direct
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 2.79429 s, 384 MB/s
root@pve ~ # dd if=/dev/zero of=iotestfile552 bs=1G count=1 oflag=direct
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 2.8197 s, 381 MB/s
root@pve ~ # dd if=/dev/zero of=iotestfile552 bs=1G count=1 oflag=direct
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 3.48254 s, 308 MB/s
root@pve ~ # dd if=/dev/zero of=iotestfileasd2 bs=1G count=1 oflag=direct
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 2.81833 s, 381 MB/s
 
A

andreas0

Guest
@Vengance:
Prüfe mal mit dem Befehl "fdisk -l", ob die beiden SSDs tatsächlich im RAID 1 Verbund arbeiten. Und stell uns danach mal zusätzlich auch das Ergebnis hier in Forum rein. Denn ich befürchte, dass die beiden SSDs nicht im RAID 1 Verbund geschaltet sind.
 

Vengance

Member
Code:
Disk /dev/sda: 238.5 GiB, 256060514304 bytes, 500118192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x2db56a47

Device     Boot   Start       End   Sectors  Size Id Type
/dev/sda1          2048   1050623   1048576  512M fd Linux raid autodetect
/dev/sda2       1050624 500116143 499065520  238G fd Linux raid autodetect


Disk /dev/sdb: 238.5 GiB, 256060514304 bytes, 500118192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0xf1f3900c

Device     Boot   Start       End   Sectors  Size Id Type
/dev/sdb1          2048   1050623   1048576  512M fd Linux raid autodetect
/dev/sdb2       1050624 500116143 499065520  238G fd Linux raid autodetect


Disk /dev/md0: 511.4 MiB, 536281088 bytes, 1047424 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/md1: 237.9 GiB, 255387303936 bytes, 498803328 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/mapper/vg0-root: 10 GiB, 10737418240 bytes, 20971520 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/mapper/vg0-swap: 6 GiB, 6442450944 bytes, 12582912 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/mapper/vg0-vm--101--disk--1: 20 GiB, 21474836480 bytes, 41943040 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 131072 bytes / 131072 bytes
Disklabel type: dos
Disk identifier: 0xb729ec70

Device                                 Boot    Start      End  Sectors Size Id Type
/dev/mapper/vg0-vm--101--disk--1-part1 *        2048 33554431 33552384  16G 83 Linux
/dev/mapper/vg0-vm--101--disk--1-part2      33556478 41940991  8384514   4G  5 Extende
/dev/mapper/vg0-vm--101--disk--1-part5      33556480 41940991  8384512   4G 82 Linux s

Partition 2 does not start on physical sector boundary.


Disk /dev/mapper/vg0-vm--166--disk--1: 20 GiB, 21474836480 bytes, 41943040 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 131072 bytes / 131072 bytes
Disklabel type: dos
Disk identifier: 0xb729ec70

Device                                 Boot    Start      End  Sectors Size Id Type
/dev/mapper/vg0-vm--166--disk--1-part1 *        2048 33554431 33552384  16G 83 Linux
/dev/mapper/vg0-vm--166--disk--1-part2      33556478 41940991  8384514   4G  5 Extende
/dev/mapper/vg0-vm--166--disk--1-part5      33556480 41940991  8384512   4G 82 Linux s

Partition 2 does not start on physical sector boundary.


Disk /dev/mapper/vg0-vm--102--disk--1: 40 GiB, 42949672960 bytes, 83886080 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 131072 bytes / 131072 bytes
Disklabel type: dos
Disk identifier: 0xcfc43bc7

Device                                 Boot   Start      End  Sectors  Size Id Type
/dev/mapper/vg0-vm--102--disk--1-part1 *       2048  1026047  1024000  500M  7 HPFS/NT
/dev/mapper/vg0-vm--102--disk--1-part2      1026048 83884031 82857984 39.5G  7 HPFS/NT



Code:
cat /proc/mdstat
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md1 : active raid1 sda2[0] sdb2[1]
      249401664 blocks super 1.2 [2/2] [UU]
      bitmap: 1/2 pages [4KB], 65536KB chunk

md0 : active raid1 sdb1[1] sda1[0]
      523712 blocks super 1.2 [2/2] [UU]

unused devices: <none>
 
A

andreas0

Guest
Nun ist die IO Performance mal wieder besser.. Hält aber wahrscheinlich wieder nur kurz an.

Sind denn die virtuellen Maschinen 101, 102 und 166 während deiner Tests und auch sonst immer gestartet?
 

Vengance

Member
Die waren dauerhaft gestartet, ja.
Die sind aber alle im idle und erzeugen jeweils nicht mehr als ein paar hundert kb/s.
 
Top