it-swarm.com.de

Ubuntu SSD - War schnell, ist jetzt extrem langsam

Dies ist, was ich jetzt bekomme, mit einer Crucial MX300 750 GB SSD (mit der neuesten Firmware [es gibt noch keine Firmware-Updates]).

lptp [ blah ]: Sudo hdparm -Tt /dev/sda

/dev/sda:
 Timing cached reads:   10202 MB in  2.00 seconds = 5103.20 MB/sec
 Timing buffered disk reads: 128 MB in  3.06 seconds =  41.88 MB/sec

Sehen Sie sich die Lesegeschwindigkeit der gepufferten Festplatte an !!!! SOOOO LANGSAM !!!! Als ich meinen Laptop zum ersten Mal einrichtete, sah ich über 400 MB/Sek., Was für mich völlig in Ordnung war, da es sich um einen älteren Laptop handelt. und alles ist in Ordnung.

Dies ist mein /etc/fstab. Ich habe das Zuschneiden aktiviert, das Zuschneiden manuell ausgeführt, die Funktionen aktiviert/deaktiviert und alles neu gestartet. Ich kann diese hohen Geschwindigkeiten nicht zurückbringen:

/dev/mapper/ubuntu--gnome--vg-root /               ext4    noatime,nodiratime,errors=remount-ro,barrier=0,discard 0       1

Nur damit klar ist, das sind die Optionen, die ich benutze. Ich habe verschiedene Kombinationen von ihnen ohne Erfolg versucht:

noatime,nodiratime,errors=remount-ro,barrier=0,discard

Irgendwelche Tipps? Das macht mich verrückt.

Ach ja, ich verwende Ubuntu 16.04 (x64) auf einem Lenovo T420 mit 16 GB RAM und einem i7-Prozessor:

 lptp [ blah ]: lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 16.04.1 LTS
Release:    16.04
Codename:   xenial

Smartctl-Ausgabe:

 lptp [ blah ]: Sudo smartctl /dev/sda -a
smartctl 6.5 2016-01-24 r4214 [x86_64-linux-4.4.0-38-generic] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Device Model:     Crucial_CT750MX300SSD1
Serial Number:    XXXXXX
LU WWN Device Id: 5 XXXXX XXXXXXX
Firmware Version: M0CR011
User Capacity:    750,156,374,016 bytes [750 GB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    Solid State Device
Form Factor:      2.5 inches
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   ACS-3 T13/2161-D revision 5
SATA Version is:  SATA 3.2, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Tue Nov  1 21:22:05 2016 CDT
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x00) Offline data collection activity
                    was never started.
                    Auto Offline Data Collection: Disabled.
Self-test execution status:      (   0) The previous self-test routine completed
                    without error or no self-test has ever 
                    been run.
Total time to complete Offline 
data collection:        ( 1987) seconds.
Offline data collection
capabilities:            (0x7b) SMART execute Offline immediate.
                    Auto Offline data collection on/off support.
                    Suspend Offline collection upon new
                    command.
                    Offline surface scan supported.
                    Self-test supported.
                    Conveyance Self-test supported.
                    Selective Self-test supported.
SMART capabilities:            (0x0003) Saves SMART data before entering
                    power-saving mode.
                    Supports SMART auto save timer.
Error logging capability:        (0x01) Error logging supported.
                    General Purpose Logging supported.
Short self-test routine 
recommended polling time:    (   2) minutes.
Extended self-test routine
recommended polling time:    (  10) minutes.
Conveyance self-test routine
recommended polling time:    (   3) minutes.
SCT capabilities:          (0x0035) SCT Status supported.
                    SCT Feature Control supported.
                    SCT Data Table supported.

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   100   100   000    Pre-fail  Always       -       0
  5 Reallocated_Sector_Ct   0x0032   100   100   010    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   100   100   000    Old_age   Always       -       52
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       41
171 Unknown_Attribute       0x0032   100   100   000    Old_age   Always       -       0
172 Unknown_Attribute       0x0032   100   100   000    Old_age   Always       -       0
173 Unknown_Attribute       0x0032   100   100   000    Old_age   Always       -       1
174 Unknown_Attribute       0x0032   100   100   000    Old_age   Always       -       11
183 Runtime_Bad_Block       0x0032   100   100   000    Old_age   Always       -       0
184 End-to-End_Error        0x0032   100   100   000    Old_age   Always       -       0
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -       0
194 Temperature_Celsius     0x0022   059   052   000    Old_age   Always       -       41 (Min/Max 21/48)
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   100   100   000    Old_age   Always       -       0
202 Unknown_SSD_Attribute   0x0030   100   100   001    Old_age   Offline      -       0
206 Unknown_SSD_Attribute   0x000e   100   100   000    Old_age   Always       -       0
246 Unknown_Attribute       0x0032   100   100   000    Old_age   Always       -       138859820
247 Unknown_Attribute       0x0032   100   100   000    Old_age   Always       -       4354463
248 Unknown_Attribute       0x0032   100   100   000    Old_age   Always       -       1675456
180 Unused_Rsvd_Blk_Cnt_Tot 0x0033   000   000   000    Pre-fail  Always       -       3558
210 Unknown_Attribute       0x0032   100   100   000    Old_age   Always       -       0

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
No self-tests have been logged.  [To run self-tests, use: smartctl -t]

SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

Was mich umbringt ist, dass ES FÜR EINEN ZEITRAUM GEMACHT HAT . Es funktionierte an einem Tag und hörte am nächsten auf und ich tat nicht einmal etwas (woran ich denken kann), was es hätte ändern sollen.

UPDATE

Getestet ein bestimmtes Gerät (/dev/sda1), aber die gleichen langsamen Ergebnisse:

lptp [ ~ ]: Sudo hdparm -Tt /dev/sda1

/dev/sda1:
 Timing cached reads:   13130 MB in  2.00 seconds = 6568.77 MB/sec
 Timing buffered disk reads: 128 MB in  3.06 seconds =  41.79 MB/sec

UPDATE

Auch auf einer logischen Partition getestet:

 lptp [ ~ ]: Sudo hdparm -Tt /dev/mapper/ubuntu--gnome--vg-root 

/dev/mapper/ubuntu--gnome--vg-root:
 Timing cached reads:   11468 MB in  2.00 seconds = 5736.85 MB/sec
 Timing buffered disk reads: 178 MB in  3.04 seconds =  58.47 MB/sec

UPDATE dd test

Dieser Test zeigt, dass es sogar langsamer als HDParm-Shows ist ...

 lptp [ blah ]:  dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc status=progress
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 35.0156 s, 30.7 MB/s
 lptp [ blah ]: Sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"
 lptp [ blah ]: dd if=tempfile of=/dev/null bs=1M count=1024 status=progress
1066401792 bytes (1.1 GB, 1017 MiB) copied, 34.0193 s, 31.3 MB/s
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 34.256 s, 31.3 MB/s

UPDATE: Partitionsausrichtung

Hier ist die Partitionsausrichtung auf meinem Laptop:

lptp [ ~ ]: Sudo parted
GNU Parted 3.2
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) p                                                                
Model: ATA Crucial_CT750MX3 (scsi)
Disk /dev/sda: 750GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End    Size   Type      File system  Flags
 1      1049kB  512MB  511MB  primary   ext2         boot
 2      513MB   750GB  750GB  extended
 5      513MB   750GB  750GB  logical

(parted) align-check opt 1                                                       
1 aligned
(parted) align-check opt 2
2 not aligned
(parted) align-check opt 5
5 aligned
(parted)

Ich bin nicht sicher, was ich von Partition 2 halten soll, die nicht ausgerichtet ist: ^/aber Partitionen 1 und 5 sind es trotzdem.

Hier sind auch die Partitionen aus fdisk -l

Device     Boot   Start        End    Sectors   Size Id Type
/dev/sda1  *       2048     999423     997376   487M 83 Linux
/dev/sda2       1001470 1465147391 1464145922 698.2G  5 Extended
/dev/sda5       1001472 1465147391 1464145920 698.2G 83 Linux

UPDATE: FIXED? Ich habe den Scheduler in einen Noop Scheduler geändert (anstelle von Deadline). Das scheint geklappt zu haben (hat dies getan, indem /etc/default/grub geändert wurde, um die folgende Zeile zu erhalten:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash elevator=noop"

Und dann aktualisiere grub mit Sudo update-grub2 und starte neu.

Ich werde ein paar Tage warten, um zu sehen, ob es nach ein paar weiteren Neustarts/Nutzungen funktioniert, bevor ich eine Antwort gebe und sie akzeptiere.

Aktuelle Geschwindigkeiten jetzt nach dem Ändern des Schedulers:

 lptp [ ~ ]: Sudo hdparm -Tt /dev/sda

/dev/sda:
 Timing cached reads:   12388 MB in  2.00 seconds = 6197.19 MB/sec
 Timing buffered disk reads: 1454 MB in  3.00 seconds = 484.59 MB/sec

Optionen in fstab sind:

noatime,nodiratime,errors=remount-ro,barrier=0

enter image description here

UPDATE "FIX"

Nach einigem Gebrauch und ein paar Neustarts ist es ZURÜCK ZU DEN LANGSAMEN GESCHWINDIGKEITEN :( :( :( :( :( :( :(

UPDATE - MÖGLICHES "FIX"

Ich hatte den Gedanken, dass mein Laptop möglicherweise einige akkusparende Optimierungen vornimmt, wenn er gestartet wird und der Akku leer ist. Nach einem einfachen Boot-Test mit angeschlossenem Ladegerät ist die Geschwindigkeit wieder sehr hoch. Ich bin mir ziemlich sicher, dass dies der Fall ist - die ganze Zeit wurde es mit hoher Geschwindigkeit getestet, als ich das Ladegerät angeschlossen hatte. Ich werde ein paar weitere Tests durchführen, um dies zu überprüfen, aber ich bin mir ziemlich sicher, dass dies der Grund für die Verlangsamung ist.

9
Markus Orreilly

Die schnelle Antwort:

Sudo hdparm -B254 /dev/sda

Die lange Antwort:

Es scheint, dass Linux oder Laptops im Allgemeinen (sowohl bei Lenovo als auch bei Dells überprüft) standardmäßig APM-Stufe 80h (128) beim Booten mit Akku und FEh (254) beim Booten mit Wechselstrom verwenden.

Bei den meisten SSDs werden Sie keinen großen Unterschied bemerken. Lite-on-SSDs scheinen die Energieverwaltung überhaupt nicht zu unterstützen und laufen immer mit maximaler Geschwindigkeit. Intel-SSDs scheinen bei APM-Stufe 128 mit etwa 75% und bei APM-Stufe 254/255 mit 100% Geschwindigkeit zu laufen. Entscheidende SSDs scheinen jedoch bei APM-Stufe 128 (Booten mit Batterie) mit etwa 6% voller Geschwindigkeit zu laufen, verglichen mit APM-Stufe 254 (Booten mit Wechselstrom).

Die schlechte Nachricht ist, dass es hier keinen Bug und keinen Fehler gibt. Die ATA-Spezifikation ist so vage, dass Crucial-SSDs, die im APM-Modus 128 sehr langsam laufen, zulässig sind und der Spezifikation entsprechen. Ebenso ist ein Laptop mit APM-Level 80h (128) durchaus sinnvoll. Die Spezifikation sagt nur:

Tabelle 106 - APM-Stufen
COUNT Feld Ebene
00h Reserviert
01h Minimaler Stromverbrauch im Standby-Modus
02h..7Fh Intermediate Power Management Levels im Standby-Modus
80h Minimaler Stromverbrauch ohne Standby-Modus
81h..FDh Intermediate Power Management Levels ohne Standby-Modus
FEh Maximale Leistung
FFh Reserviert

(Aus der ATA spec )

Hier sind meine Erfahrungen mit einer Crucial MX300 SSD, die im Akkubetrieb gebootet wurde:

[email protected]:~# hdparm -B /dev/sda

/dev/sda:
 APM_level  = 128

[email protected]:~# hdparm -t /dev/sda

/dev/sda:
 Timing buffered disk reads:  94 MB in  3.02 seconds =  31.11 MB/sec

[email protected]:~# hdparm -B254 /dev/sda

/dev/sda:
 setting Advanced Power Management level to 0xfe (254)
 APM_level  = 254

[email protected]:~# hdparm -t /dev/sda

/dev/sda:
 Timing buffered disk reads: 1466 MB in  3.00 seconds = 488.44 MB/sec
14
Daniel van Vugt

Sie können in /etc/hdparm.conf nachsehen, wo Sie die APM-Stufe für die Stromversorgung und den Batteriemodus konfigurieren können.

Hinzufügen

apm = 254
apm_battery = 254

zu /etc/hdparm.conf

5
christianonline

Ich stellte durchweg fest, dass ich in der Lage war, die hohen Geschwindigkeiten zu erreichen, wenn ich den Laptop beim Anschließen hochfuhr. Wenn ich den Laptop hochfuhr, während der Akku leer war, und dann eingesteckt, ich war immer noch auf die langsamen Geschwindigkeiten stecken.

Dies war möglicherweise etwas spezielles für meinen Laptop (Lenovo T420). Ich habe alle BIOS-Einstellungen geändert, um keine Energie zu sparen und maximale Leistung zu erzielen. Dies ließ es jedoch nicht die hohen Geschwindigkeiten haben, wenn nur der Akku verwendet wurde. Ich musste noch angeschlossen sein, als ich hochfuhr, um die schnellen Geschwindigkeiten zu haben.

Noch ein Hinweis: Ich kann beim Booten angeschlossen und nach dem Booten den Laptop vom Computer trennen. Der Laptop behält die hohe Geschwindigkeit bei, bis er das nächste Mal hochfährt.

ANSWER: Wird beim Booten eingesteckt.

3
Markus Orreilly

Bitte verwenden Sie einen ausreichend neuen Kernel (v4.15 +) und versuchen Sie, med_power_with_dipm für Ihren Crucial MX300 zu verwenden.

LPM min_power funktioniert nicht für alle Treiber. Wenn med_power_with_dipm für Sie funktioniert, sollten wir einen neuen Quirk verwenden, um es auf med_power_with_dipm zurückgreifen zu lassen, wenn min_power ausgewählt wird.

Bitte melden Sie auch einen Fehler im Launchpad, damit die Entwickler des Ubuntu-Kernels den Fehler beheben oder das Problem auf den Upstream übertragen können.

0
khfeng