SSD sehr lagnsam

Druckbare Version

17.06.17, 12:00
astrakid

SSD sehr lagnsam

hi,
ich betreibe einen privaten server mit debian (proxmox) und einigen VMs darauf. Im Server stecken 3 SSDs, eine kleine mit system und VMs und zwei als Datengrab. Sinn und Zweck tut hier nicht zur Sache.
Mir ist jedenfalls aufgefallen, dass das Kopieren zwischen den SSDs nur noch sehr langsam (<100MB/s) läuft. Früher lief das immer zwischen 200 und 300MB/s.
Komischerweise sagt hdparm -tT /dev/sdx eine normale Geschwoindigkeit an:

Code:

root@server:/mnt/ssd128/images/300# hdparm -Tt /dev/sda /dev/sda: Timing cached reads: 2504 MB in 2.00 seconds = 1252.65 MB/sec Timing buffered disk reads: 1328 MB in 3.00 seconds = 442.55 MB/sec root@server:/mnt/ssd128/images/300# hdparm -Tt /dev/sdb /dev/sdb: Timing cached reads: 2542 MB in 2.00 seconds = 1271.46 MB/sec Timing buffered disk reads: 1100 MB in 3.01 seconds = 366.01 MB/sec root@server:/mnt/ssd128/images/300# hdparm -Tt /dev/sdc /dev/sdc: Timing cached reads: 2508 MB in 2.00 seconds = 1253.88 MB/sec Timing buffered disk reads: 1060 MB in 3.00 seconds = 352.84 MB/sec root@server:/mnt/ssd128/images/300#

aber rsync ist echt lahm:

Code:

root@server:/mnt# rsync -av ssd1000/999_VMs/dump/vzdump-qemu-109-2016_04_20-07_38_06.vma.lzo . --progress sending incremental file list vzdump-qemu-109-2016_04_20-07_38_06.vma.lzo 1,213,005,824 38% 82.78MB/s 0:00:22 ^C

Die großen SSDs sind wirklich nur für Datenhaltung zuständig, eigentlich nur statische Daten (Fotos, Musik, Dokumente, etc). Dort dürften also quasi keine Zugriffe stattfinden, wenn nur sehr wenig und auch nur lesend.
Auch iotop ist unauffällig. Kaum Zugriffe, und wenn auf /dev/sdc (System-SSD).

Habt ihr irgendwelche Ratschläge für mich?
linux: Linux server 4.10.11-1-pve #1 SMP PVE 4.10.11-9 (Mon, 22 May 2017 09:59:55 +0200) x86_64 GNU/Linux (debian stretch).

gruß,
astrakid
17.06.17, 14:30
corresponder

Zitat:

/dev/sda:
Timing cached reads: 7492 MB in 1.99 seconds = 3755.78 MB/sec
Timing buffered disk reads: 742 MB in 3.00 seconds = 247.11 MB/sec

so sieht es bei mir mit einer samsung evo aus....

gruss

c.
18.06.17, 10:36
astrakid

ich habe auch eine evo 850.
kannst du mal eine große datei mit rsync kopieren und schauen, wie schnell das ist?
18.06.17, 10:48
corresponder

Zitat:

sent 2197170166 bytes received 31 bytes 15750323.99 bytes/sec
total size is 2196901888 speedup is 1.00

das war eine 2,1GB grosse datei
wurde in 140sec kopiert= 15mb sec
allerdings von ssd1 zu ssd1

gruss

c.
18.06.17, 11:18
astrakid

Zitat:

sending incremental file list
vzdump-qemu-109-2016_04_20-07_38_06.vma.lzo
3,111,289,622 100% 79.61MB/s 0:00:37 (xfr#1, to-chk=0/1)

sent 3,112,049,341 bytes received 35 bytes 82,987,983.36 bytes/sec
total size is 3,111,289,622 speedup is 1.00

das war auf der evo 850. auf meiner crucial erreiche ich qasi das gleiche:

Zitat:

vzdump-qemu-109-2016_04_20-07_38_06.vma.lzo
3,111,289,622 100% 68.87MB/s 0:00:43 (xfr#1, to-chk=0/1)

sent 3,112,049,341 bytes received 35 bytes 71,541,364.97 bytes/sec
total size is 3,111,289,622 speedup is 1.00

hier scheint irgendwas anderes zu bremsen...
18.06.17, 11:26
corresponder

was sagt denn ein "top" oder "dmesg"?

gruss

c.
18.06.17, 15:43
astrakid

cpu geht auf 100%. egal ob innerhalb einer ssd oder von einer zur anderen.

[ 1.932090] ata1: SATA max UDMA/133 abar m1024@0xffb6a000 port 0xffb6a100 irq 35
[ 2.402572] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 2.404610] ata1.00: supports DRM functions and may not be fully accessible
[ 2.411212] ata1.00: NCQ Send/Recv Log not supported
[ 2.411215] ata1.00: ATA-9: Samsung SSD 850 EVO 1TB, EMT01B6Q, max UDMA/133
[ 2.411219] ata1.00: 1953525168 sectors, multi 1: LBA48 NCQ (depth 31/32), AA
[ 2.411482] ata1.00: supports DRM functions and may not be fully accessible
[ 2.418202] ata1.00: NCQ Send/Recv Log not supported
[ 2.418289] ata1.00: configured for UDMA/133

edit: cp läuft deutlich schneller:

root@server:/mnt# ls -l /mnt/ssd1000/999_VMs/dump/vzdump-qemu-109-2016_04_20-07_38_06.vma.lzo
-rw-r--r-- 1 root root 3111289622 Apr 20 2016 /mnt/ssd1000/999_VMs/dump/vzdump-qemu-109-2016_04_20-07_38_06.vma.lzo
root@server:/mnt# time rsync -a /mnt/ssd1000/999_VMs/dump/vzdump-qemu-109-2016_04_20-07_38_06.vma.lzo /mnt/ssd1000/test.lzo

real 0m37,692s
user 0m32,292s
sys 0m20,272s
root@server:/mnt# time cp /mnt/ssd1000/999_VMs/dump/vzdump-qemu-109-2016_04_20-07_38_06.vma.lzo /mnt/ssd1000/test.lzo

real 0m19,322s
user 0m0,024s
sys 0m13,572s
root@server:/mnt#
18.06.17, 18:52
nopes

Ein bisschen Vorbehalt. Es ist normal das rsync länger als cp braucht. Es ist auch normal das rsync viel mehr CPU Zeit braucht, als zB cp.

Solltest du aber noch mal genau prüfen, ob das noch so ist. Ist ein paar Jahre her:
https://superuser.com/questions/6142...isk-to-another
https://lwn.net/Articles/400489/
19.06.17, 06:09
astrakid

das ist natürlich ein guter hinweis... danke, das war mir nicht bewusst!
19.06.17, 08:47
ThorstenHirsch

Ist trotzdem noch nicht optimal, oder? rsync hat 38s gebraucht, das waren 80MB/s und cp braucht 19s, das wären 160MB/s . Deine Platten schaffen aber über 320MB/s, also das doppelte. Kann es am Controller liegen? Der schafft 6GB/s, das sind 750MB/s. Also selbst wenn man das halbiert (wegen hin und zurück), sind die 320MB/s drin. Also ich denke, da lässt sich noch mehr rausholen. Vielleicht schaust Du mal nach Kernel-Parametern für den SATA-Controller, irgendwas mit DMA oder so.

P.S.: Alle Werte sind so gerundet, dass man Faktor 2 sieht.
19.06.17, 15:53
astrakid

ne, optimal ist die performance immer noch nicht, aber verkraftbar. da es ein sehr sparsamer server ist, erwarte ich auch nicht die performance. daher habe ich auch nur billig-ssds drin - das reicht.