[gelöst - irgendwie] SSD extremst langsam

  • Jetzt habe ich auch so einen komischen Fall, wo ich mir nicht wirklich einen Reim drauf machen kann:


    Eine neue (~ 1/2 Jahr) SSD ist ohne sonstige Probleme extremst langsam geworden:

    Code
    hdparm -tT --direct /dev/sda
    
    /dev/sda:
     Timing O_DIRECT cached reads:   158 MB in  2.02 seconds =  78.36 MB/sec
     Timing O_DIRECT disk reads: 194 MB in  3.00 seconds =  64.60 MB/sec

    Mit jedem weiteren Versuche wird es noch schlechter, bis es sich irgendwann einpendelt:

    Code
    hdparm -tT --direct /dev/sda
    
    /dev/sda:
     Timing O_DIRECT cached reads:    26 MB in  2.12 seconds =  12.26 MB/sec
     Timing O_DIRECT disk reads:  38 MB in  3.19 seconds =  11.90 MB/sec

    Das muss Jahrzehnte her sein, dass ich so Werte bei einer Festplatte gesehen habe. :achdufresse


    Wenn man etwas wartet wird es meist wieder besser und man kann das Spiel erneut beginnen.


    Das Modell (Crucial BX500 240Mb) ist sicher kein Performance-Wunder, aber für einen einfache Bürorechner sollte die eigentlich doch tun?

    Der Rechner brauch inzwischen deutlich über 5 Minuten zu Booten. Selbst surfen im Internet ist mit dem Teil inzwischen ein Geduldsspiel.


    Als ich den Rechner vor etwa 1/2 Jahr neu aufgesetzt und diese SSD eingebaut habe, ist mir nichts aufgefallen. Die SSD sollte damals also eigentlich noch einigermassen flott gewesen sein.


    Ausser der fehlenden Geschwindigkeit macht die SSD aber keine Probleme.

    Laut SMART ist alles in Ordnung.

    Alle Fehlergrößen stehen immer noch bei RAW 0.

    Auch der Selbsttest ist fehlerfrei durchgelaufen.

    Selbst die Temperatur ist nie über 50°C gegangen.


    Alignment stimmt und getrimmt wird die SSD auch (beides nachgeprüft).

    Und in den logfiles habe ich auch nichts verdächtiges gesehen.


    Die alte Festplatte, die auch noch drin ist, läuft hingegen wie immer:

    Code
    hdparm -tT --direct /dev/sdb
    
    /dev/sdb:
     Timing O_DIRECT cached reads:   166 MB in  2.00 seconds =  82.98 MB/sec
     Timing O_DIRECT disk reads: 232 MB in  3.03 seconds =  76.69 MB/sec

    Ein genereller Fehler scheint also nicht vorzuliegen.


    Wenn man nach dem Modell im Netz sucht, findet man Berichte über Überhitzung. Aber alles eher vage.

    SMART zeigte bei meinen Tests aber nie mehr als 35°C an.


    Falls jemand eine Idee hat was da los sein könnte, das raus damit :) .

    Wesentlich mehr als austauschen und hoffen fällt mir jedenfalls nicht mehr ein.

    Gruss
    SHF


  • Backup erstellen und schleunigst den Wechsel der SSD vorbereiten. 1TB liegt aktuell unter 50€.


    So ähnlich war das bei einer SSD von mir - kurz drauf war sie im BIOS nicht mehr zu sehen.

  • Schon mal fstrim probiert?

  • Alte Samsungs (840 IIRC) hatten mal 'nen Bug dass Sektoren, die nur gelesen wurden, immer langsamer wurden. Wurde mit 'nem Firmware-Update korrigiert. Ansonsten ist in der Tat fstrim 'ne gute Idee, vor allem wenn die Platte recht voll ist.

    Eigentlich sollten aber aktuelle systeme die SSD mit entsprechenden Parametern mounten.

    Da sie nicht so gross ist würde ich mal versuchen die Daten zu sichern, die Platte neu formatieren und Daten zurückspielen...


    Ach so, und natürlich auf jeden Fall SMART anschauen (ich nutz meist gsmartcontrol) und evtl. dort 'nen Selbst-Test starten

    VDR2: ASRock J4105-ITX, DVBSky S952, openSUSE Tumbleweed, VDR 2.4.7

    softhddevice/vaapidevice, DFAtmo, xmltv2vdr, tvscraper, tvguideng, VDRAdmin-AM (alles git, aber alt)

  • Hi,

    Gibts evtl nen Firmware Update?

    MfG Stefan

    Test-VDR1: HP rp5700 Fertigsystem, Core2Duo E6400, 2GB RAM, FF-SD C-2300, nvidia Slim-GT218 x1 | easyVDR 2.0 64Bit
    VDR3: in Rente

    VDR4: MSI G31M2 v2, Digitainer2-Geh., t6963c 6" gLCD, E5200, 2GB, 3TB WD Red, GT730, 2x TT S2-3200; easyVDR 3.5 64bit
    VDR5: Gigabyte
    GA-G31M-S2L, Intel E2140, Zotac GT730 passiv, Digitainer2-Geh., t6963c 6 " gLCD, 2 TB WD Red, 2x TT S2-3200 (an 1 Kabel) easyVDR 3.5 64bit
    VDR6:
    Intel E5200, GT630 passiv, F1 750 GB, t6963c gLCD, 2x TT S2-3200 | easyVDR 3.5 64bit
    VDR-User #1068
    www.easy-vdr.de

  • Hallo zusammen und danke für die Anregungen.

    - kurz drauf war sie im BIOS nicht mehr zu sehen.

    Den Fall hatte ich inzwischen auch schon 3 mal.

    Allerdings ohne jegliche Vorwarnung.


    Deshalb wird bei allen "meinen" SSDs auch täglich automatisiert ein Backup der wichtigen Daten erstellt.

    (Das ist auch der Grund, warum die Festplatte noch drin ist.)


    Um Daten mache ich mir da also keine Sorgen, zumal sowieso nichts wichtiges drauf ist. Der Rechner wird eigentlich auch nur fürs Surfen, Emails und dergleichen verwendet.


    Schon mal fstrim probiert?

    Ja, gestern gemacht.

    Ist dadurch aber auch über Nacht nicht wirklich schneller geworden :( .

    Direkt nacheinander ausgeführt!

    Der Einbruch der Leistung ist immer wieder verblüffend.


    Im Prinzip scheint das Teil noch immer schneller zu können, aber es will nicht.

    Das Verhalten grenzt doch schon an Leistungsverweigerung durch Bummelstreik :motz4 .


    Eigentlich sollten aber aktuelle systeme die SSD mit entsprechenden Parametern mounten.

    Die SSD ist mit "discard" gemountet und auch korrekt partitioniert. (gestern nochmal überprüft)

    Belegung liegt auch nur bei gut 1/3.


    Da sie nicht so gross ist würde ich mal versuchen die Daten zu sichern, die Platte neu formatieren und Daten zurückspielen...

    Bei der "Geschwindigkeit" würde das aber trotzdem, grob geschätzt, 5 Stunden dauern :wow .

    Da der Rechner nicht direkt bei mir steht, müsste ich ihn bei der Dauer abbauen, was ich eigentlich vermeiden wollte. Remote geht sowas ja leider nicht.


    Tauschen… . Und dann kann man mit der SSD immer noch experimentieren.

    Ich befürchte darauf wird es hinaus laufen. Am Objekt experimentieren ist im aktuellen Fall nicht praktikabel.

    Ausserdem ist noch Garantie drauf, wenn ich das Teil einschicken muss, brauche ich eh Ersatz.


    Vielleicht bringt das Auslesen der SMART-Werte mit smartctl einen Hinweis auf das Problem

    Laut SMART-Werten ist die SSD neuwertig.

    Sämtliche Werte sind noch bei 100.

    Selbst die raw-Werte sind bei allen Fehlern noch 0.

    Keine 1000 Stunden gelaufen und Percent_Lifetime_Remain 100%.

    Auch der Selbsttest ist fehlerfrei durchgelaufen.


    Das einzige, was mir jetzt beim zweiten hinsehen auffällt, ist die recht hohe Power_Cycle_Count und Unexpected_Power_Loss_Ct.

    Bislang hatte ich das auf das typische Benutzerverhalten geschoben :whatever , aber die Veränderungen gegenüber dem letzten Abruf sind irgendwie verdächtig:


    Power_On_Hours:+14

    Power_Cycle_Count: +15

    Unexpected_Power_Loss_Ct: +1

    Wobei ich erst noch mal schauen muss, was das letzte Wert überhaupt genau aussagt, das ist bislang das erste Laufwerk, was den liefert.

    "Unexpected Power Loss" klingt stark aber so, als ob es besser nicht auftreten sollte ;) .


    Ich denke, ich werde die SSD doch mal mit einen USB-Adapter testen, das ist schnell gemacht.

    Vielleicht stimmt doch irgendwas bei dem Rechner / Netzteil nicht.

    Gibts evtl nen Firmware Update?

    Laut Crucial-Website:

    "Im Moment keine Firmware-Updates."

    Gruss
    SHF


  • Vielleicht liegt es auch am Datenkabel und/oder an den Kontakten.

  • Vielleicht liegt es auch am Datenkabel und/oder an den Kontakten.

    Normalerweise gibt das Meldungen im Syslog und SMART-Fehler.

    UDMA_CRC_Error_Count ist 0, daher eher unwahrscheinlich.



    An der hohen "Unexpected_Power_Loss_Ct" scheint aber was dran zu sein.

    Bei mir kommt ungefähr ein "Unexpected_Power_Loss" auf 5 "Power_Cycles", das ist definitiv zu viel. Für Stomausfälle und "versehentlich den Stecker ziehen" ist das viel zu viel.


    Etwas Suche förderte dieses zu Tage:

    https://lore.kernel.org [...] Race to power off harming SATA SSDs

    Es ist also bekannt, dass Linux für einige SSDs zu früh den Strom abdreht.

    Besonders betroffen scheinen Micron / Crucial SSDs zu sein, auch die Samsung 840 wurde erwähnt.

    Leider ist bei der Diskussion wohl nicht wirklich was raus gekommen, da wurde, trotz guter Argumente, eher versucht das Problem weg zu diskutieren, als es zu lösen :( .

    Ob seit dem doch was im Kernel getan wurde muss ich aber noch mal schauen.


    Ich überlege jetzt, ob man einfach vor dem ei?entlichen irgendwie eine Sekunde sleep hinzufügen kann, ohne an den Kernel ran zu müssen.

    Wenn jemand dazu eine Idee hat, würde es mich freuen.

    Das müsste irgendwo zwischen dem aushängen der SCSI-Disks und dem Strom-Abstellen rein.

    Kommt man an die Stelle noch mit systemd oder einem Skript hin? Ich befürchte mal nicht.

    Gruss
    SHF


  • So, die "Unexpected_Power_Loss" sind wieder gestiegen und das im Durchschnitt um mehr als eine pro Tag.

    (Bei 200 "Unexpected_Power_Loss" in einem halben Jahr auch kein Wunder, mit etwas Kopfrechnen hätte mir das schon letzte Woche auffallen müssen. :whatever )


    Inzwischen hatte ich aber auch schon Tests mit 300 MB/sec und dann wieder so langsame.


    Ich habe, als Sofortmaßnahme, mal "suspend to Disk" deaktiviert und den Benutzer gebeten den Benutzer gebeten den Rechner nicht unnötig oft hoch und runter zu fahren.

    Sicher keine Dauerlösung, aber hoffentlich hält die SSD so durch, bis Ersatz da ist.


    Da stellt sich dann die Frage, was nimmt man. Nochmal Micron / Crucial wohl eher nicht.

    Ich pflege noch einen weiteren Computer mit derartigem Einsatzprofil. In dem verrichtet eine 0815 Emtec SSD seit 4 Jahren klaglos den Dienst. Kurioser weise soll in beiden SSDs der gleiche Controller verbaut sein. Das hilft also auch nicht weiter :wacko: .

    Gruss
    SHF


  • Nochmal Micron / Crucial wohl eher nicht.

    Weil Du Probleme mit einer Crucial BX500 hast?


    Dazu sehe ich Dich nur an der SSD "rum doktor'n" und nicht evtl. mal eruieren, ob die Probleme woanders herkommen könnten, Mainboard, Verkabelung, Netzteil, Temperaturen, Umfeld ... mir stellt sich da eher die Frage ob der Ersatz nicht ebenso (bald) kaputt geht ...


    Seit ich SSDs einsetze ist mir noch nie eine SSD kaputt gegangen, weder von Intel, Micron, Crucial, Western Digital, SanDisk noch von inzwischen auch mal welchen von Samsung. Laufen alles ausnahmslos, alte kleine SATA SSDs bilden hier inzwischen sogar einen Stapel. Aktuell laufen hier je eine Crucial MX500 (1 & 2 TB) als Video-SSD in zwei VDRs, 4x Samsung QVO 4TB in meinem Server, 4x Intel DC SSD in einem weiteren Server und alle Notebooks, PCs, VDRs und Server booten von Western Digital NVMe Modulen (Server im RAID1) bzw. haben PCs zusätzlich WD NVMe Daten SSDs.


    Habe sogar zwei NVMe Module von Intel, die beide mit deutlich über 100% wear level immer noch laufen (würden) ... setze ich aber inzwischen nicht mehr ein ...

    HowTo: APT pinning

    6 Mal editiert, zuletzt von fnu ()

  • Ich habe einen Schuhkarton voller aussortierter SATA Daten und Powerkabel. Die sind nämlich nicht für viele An-/Absteckvorgänge ausgelegt und gehen öfter kaputt. Das fiese ist, dass sie meist nicht völlig kaputt gehen, sondern "nur" einen Wackelkontakt haben.

    Auch ein starker Verbraucher am selben Netzteilstrang kann Probleme machen.

  • Mit PCIe kam auch das Link State Power Management damit Rechner weniger Strom verbrauchen, gibt es auf für SATA Verbindungen. Das kann vom Bios und vom Betriebssystem gesteuert werden. Mit dem Tool powertop kannst man sich die aktuellen Werte anzeigen, dazu mit mehrfach Tab wechseln zu den Tunables. Mit dem Cursor kann man eine EInstellung auswählen und mit Enter ändern, der dazugehörige Befehl wird dann oben angezeigt damit man ihn in ein Init Scipt kopieren kann (boot.local bei Suse). Möglicherweise kann man damit den Unexpected_Power_Loss_Ct niedrig halten bis Ersatz da ist.

    Bei mit sind bei allen Linux Systemen alle Tunables auf Good bis auf WOL und ich haben damit keine Probleme.


    Ich tippe wie schon andere vor mir auf schlechte Hardware, Mainboard oder das Kabel.


    Firmware Updates für SSDs sind nach meiner Erfahrung selten, ich habe mehr als 12 verschiedene SSDs von verschiedenen Herstellern benutzt und bisher erst 2 Firmwareupdates gehabt, bei Kingston und Samsung.

  • Das Problem ist, wie schon weiter oben erwähnt, dass der Rechner nicht bei mir steht und ich ihn auch nicht länger mitnehmen kann.


    Mehr als eine Sichtkontrolle ging bislang nicht, auch weil ich nicht das Richtige dabei hatte. Mit einen Fehler an der SSD hatte ich damals nicht gerechnet.

    Überhitzung und defekte Lüfter konnte ich aber ausschliessen.

    Auch die Stecker sitzen alle korrekt.


    Da "suspend to Disk" jetzt deaktiviert ist, sollten Power_Cycle_Count und Unexpected_Power_Loss_Ct eigentlich nicht mehr so schnell ansteigen.

    Wenn doch, ist irgendwas mit der Stromversorgung faul.


    Ich denke, ich werde die SSD doch mal mit einen USB-Adapter testen, das ist schnell gemacht.

    Vielleicht stimmt doch irgendwas bei dem Rechner / Netzteil nicht.

    Das wird der nächst Schritt sein, ich hoffe ich komme am WE dazu.

    Da kann kann ich auch ein anderes Kabel versuchen.


    Weil Du Probleme mit einer Crucial BX500 hast?

    Nein, weil anscheinend ausgerechnet Crucial und Micron SSDs mit dem Shutdown-Verhalten von Linux (und Windows 7) besonders Probleme haben sollen. Fast alle Fehlerberichte betreffen den Hersteller. Und dieser Rechner wird nunmal dauern hoch und runter gefahren.


    Es wird vermutet, dass Crucial/Micron die SATA-Spezifikation im Punkt "properly comleted" anders auslegen, als die Kernel-Macher.

    Unexpected power loss can be avoided by preceding a power off with an ATA STBI
    (STANDBY IMMEDIATE) command, and allowing the SSD to properly complete this
    command before removing power to the SSD.

    Berichten zu folge verschwinden die Unexpected_Power_Loss bei einfügen von einer Sekunde sleep vor dem Strom abdrehen.


    Evtl. trifft es andere SSD aber genau so, man sieht es nur nicht, weil der Counter fehlt. Ist schwer zu sagen, was da dran ist.


    Ich könnte jetzt natürlich nochmal die gleich SSD kaufen und schauen, ob der Fehler reproduzierbar ist. Aber will ich das??? :schiel


    Bei mit sind bei allen Linux Systemen alle Tunables auf Good bis auf WOL und ich haben damit keine Probleme.

    Ditto. Auch bei diesen Rechner.

    Gruss
    SHF


  • Ich hoffe doch es wurde in der Zwischenzeit ein Backup aller wichtiger Daten von dem System gezogen?

    Natürlich.

    Sonst hätte ich auch nicht die Ruhe mir das so anzusehen ;) .


    Am USB-Konverter ist die Performance der SSD leider ähnlich:

    591396864 Bytes (591 MB, 564 MiB) kopiert, 33,7239 s, 17,5 MB/s

    hdparm und smartctl gehen mit dem Adaper leider nicht, daher mit dd getestet.


    Interessanter Weise erhöht sich beim mehrfachen lesen der selben Datei die Geschwindigkeit hier, schwankt aber trotzdem stark:

    176 MB/s 83,6 MB/s 54,8 MB/s 188 MB/s 83,6 MB/s 50,1 MB/s

    Jeweils mit löschen des Caches dazwischen:

    echo 3 | sudo tee /proc/sys/vm/drop_caches

    Die Werte entsprechen denen im Ziel-Rechner aber ganz gut:

    12,08 MB/s 55,6 MB/s 74,4 MB/s 


    Inzwischen ist die SSD übrigens mit neuen Kabeln an einem anderen SATA-Port angeschlossen.

    Auf die Geschwindigkeit hat sich das aber nicht ausgewirkt.


    Inzwischen habe ich es aber geschafft einen SMART-Fehler zu produzieren:

    194 Temperature_Celsius 0x0022 070 038 050 Old_age Always In_the_past 30 (Min/Max 20/62)

    Das ist passiert, als die SSD am USB-Adapter auf dem Schreibtisch lag. Das Teil ist dabei aber nicht mal handwarm geworden. Ehrlich gesagt, ist mir das in all den Jahren auch noch nie passiert.


    Anscheinend gibt es von dieser SSD-Serie aber 2 Versionen:

    Eine mit Aluminium-Boden, auf den die ICs mit Wärmeleitpads montiert sind.

    Dann eine mit Vollkunststoff-Gehäuse, ohne Wärmeleitpads und dergleichen.

    Ich habe natürlich die letztgenannte "Joghurtbecher-Version" erwischt.



    Kurioser Weise kann die SSD aber doch schnell, wenn man sie komplett einliest :wow :

    sudo dd if=/dev/sdd of=/dev/null bs=1M

    240057409536 Bytes (240 GB, 224 GiB) kopiert, 743,883 s, 323 MB/s

    Das ist auch reproduzierbar:

    240057409536 Bytes (240 GB, 224 GiB) kopiert, 762,695 s, 315 MB/s

    240057409536 Bytes (240 GB, 224 GiB) kopiert, 981,286 s, 245 MB/s

    240057409536 Bytes (240 GB, 224 GiB) kopiert, 763,513 s, 314 MB/s

    Auch im Zielrechner:

    240057409536 Bytes (240 GB, 224 GiB) kopiert, 1145,19 s, 210 MB/s


    Einfach zufällig Blöcke heraus picken, klappt aber nicht:

    dd if=/dev/sda of=/dev/null bs=1M count=4096 skip=4096

    4294967296 Bytes (4,3 GB, 4,0 GiB) kopiert, 123,511 s, 34,8 MB/s

    Diverse Blöcke (vorne, hinten, mitte) haben alle in etwa diese Geschwindigkeit.


    Die letzten Ergebnisse sind für mich nun gänzlich verwirrend. Wie kann das passieren?

    240 GB können in keinen Cache passen, die Geschwindigkeit muss also echt sein.

    Das heisst, irgendwas bremst beim Lesen kleinerer Blöcke drastisch (wobei 4,0 GiB nicht wirklich klein ist).


    Laut hdparm steht der Energiesparmodus bei der SSD bei 254, also "max performance". Abschalten (255) brachte aber auch nichts.

    Was könnte es denn noch sein?

    Gruss
    SHF


  • Blöde Idee wahrscheinlich: Könnte die Blockgröße beim Formatieren eine Rolle spielen?

    Sind die inodes durcheinander?

    MyVDR: yaVDR-Ansible (Ubuntu 20) - softhddevice-openglosd (ffmpeg 2.8) - epgd/epg2vdr - skindesigner estuary4vdr (adaptiert) - 1920x1080@50 Hz | kodi 18 - inputstream + amazon vod
    Aerocube M40 | 300W | ASRock H61M-GE | Intel G530 | Asus ENGT520 | 2 x TT-budget S2-3200 | ASRock Smart Remote (CIR) | 4 GB RAM | 120 GB SSD | 3 TB HDD

  • Klingt, als wäre die SSD falsch formatiert..

  • Einfach zufällig Blöcke heraus picken, klappt aber nicht

    Mein Fehler, es klappt doch.

    Ich hätte nicht an der Blockgrösse drehen dürfen, mit "bs=1M" geht es.

    Ab ca. 10GB aufwärts liefert die SSD 130-150MB/s.

    Darunter nur etwa 50MB/s.



    Das Kling in der Tat nach einem alignment Fehler.

    Blöde ist nur, dass ich das als erstes überprüft und ausgeschlossen habe.

    Den Verdacht hatte ich schon zu Anfang, weil ich dieses Mal die Partitionierung dem Debian-Installer überlassen habe. Das hatte ich seit Ewigkeiten nicht mehr gemacht.


    Das Alignment stimmt lauf fdisk und partet. Gparted werde ich bei Gelegenheit aber noch mal versuchen.

    Block size ist 4096 und auch bei den anderen Angaben von tune2fs sehe ich im Vergleich keine verdächtigen Unterschiede.

    Wenn da was falsch ist, sehe ich das einfach nicht.

    Gruss
    SHF


Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!