Anzeige:
Ergebnis 1 bis 11 von 11

Thema: SSD sehr lagnsam

  1. #1
    Registrierter Benutzer
    Registriert seit
    Mar 2012
    Beiträge
    38

    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

  2. #2
    kleine schwester von root Avatar von corresponder
    Registriert seit
    May 2002
    Ort
    192.67.198.56
    Beiträge
    4.578
    /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.
    _______________________________________

    www.audio4linux.de - musik machen mit offenen quellen!

  3. #3
    Registrierter Benutzer
    Registriert seit
    Mar 2012
    Beiträge
    38
    ich habe auch eine evo 850.
    kannst du mal eine große datei mit rsync kopieren und schauen, wie schnell das ist?

  4. #4
    kleine schwester von root Avatar von corresponder
    Registriert seit
    May 2002
    Ort
    192.67.198.56
    Beiträge
    4.578
    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.
    Geändert von corresponder (18.06.17 um 11:51 Uhr)
    _______________________________________

    www.audio4linux.de - musik machen mit offenen quellen!

  5. #5
    Registrierter Benutzer
    Registriert seit
    Mar 2012
    Beiträge
    38
    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:
    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...

  6. #6
    kleine schwester von root Avatar von corresponder
    Registriert seit
    May 2002
    Ort
    192.67.198.56
    Beiträge
    4.578
    was sagt denn ein "top" oder "dmesg"?

    gruss

    c.
    _______________________________________

    www.audio4linux.de - musik machen mit offenen quellen!

  7. #7
    Registrierter Benutzer
    Registriert seit
    Mar 2012
    Beiträge
    38
    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#
    Geändert von astrakid (18.06.17 um 17:04 Uhr)

  8. #8
    Registrierter Benutzer
    Registriert seit
    Apr 2009
    Ort
    Erde
    Beiträge
    2.814
    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/
    Gruß nopes
    (,,,)---(^.^)---(,,,) /var/log/messages | grep cat

  9. #9
    Registrierter Benutzer
    Registriert seit
    Mar 2012
    Beiträge
    38
    das ist natürlich ein guter hinweis... danke, das war mir nicht bewusst!

  10. #10
    Registrierter Benutzer Avatar von ThorstenHirsch
    Registriert seit
    Nov 2002
    Beiträge
    6.556
    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.
    ¡Nuestro amigo... el Computador!

  11. #11
    Registrierter Benutzer
    Registriert seit
    Mar 2012
    Beiträge
    38
    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.

Ähnliche Themen

  1. sehr sehr dringendes libc.so.6 Problem (und knifflig noch dazu *g*) HIIILLLFFEEEE
    Von mettwurst im Forum System installieren und konfigurieren
    Antworten: 16
    Letzter Beitrag: 11.04.14, 00:43
  2. Sound sehr sehr sehr leise
    Von mrmoe2007 im Forum Musik
    Antworten: 5
    Letzter Beitrag: 05.11.07, 07:10
  3. kopete und kontact brachen sehr, sehr lange zum starten
    Von shb im Forum Anwendungen Allgemein, Software
    Antworten: 2
    Letzter Beitrag: 26.03.07, 22:34
  4. sftp sehr sehr sehr langsam :-(
    Von schnippi im Forum Linux als Server
    Antworten: 12
    Letzter Beitrag: 20.11.05, 10:47
  5. Antworten: 4
    Letzter Beitrag: 15.11.04, 21:51

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •