T480s schlechte Nvme-Writeperformance

[evidence]

Hallo Zusammen,

ich stelle seit einigen Tagen fest, dass meine Nvme-Leistung stark in den Keller geht. Das Phänomen äußert sich meistens, wenn ich von meinem NAS große Datenmengen (viele kleine Dateien) kopiere. Hierbei wird mein System sehr langsam bzw. freezt teilweise für einige Sekunden. Ich habe es aber auch schon festgestellt, wenn ich via USB auf die Nvme kopiere. Der Laptop ist ca. 1 Jahr alt (Neukauf). Ich schreibe jetzt auch nicht täglich x GB an Daten auf die Festplatte, daher wundert es mich doch etwas, dass die Performance nach kurzer Zeit so mau ausfällt.

Woran kann das liegen? Hat Lenovo einfach eine schlechte Platte verbaut und ich muss mir was Besseres kaufen (Samsung 970 pro)?

Infos: Arch, Kernel: 5.3.8-arch1-1 , LUKS + LVM, Testweise mit LTS-Kernel gebootet. Leider kein Unterschied feststellbar.

sudo nvme list
Node             SN                   Model                                    Namespace Usage                      Format           FW Rev  
---------------- -------------------- ---------------------------------------- --------- -------------------------- ---------------- --------
/dev/nvme0n1     FBFB180305D0000075   LENSE20512GMSP34MEAT2TA                  1           0,00   B / 512,11  GB    512   B +  0 B   2.8.8341

dd if=/dev/zero of=test_$$ bs=64k count=16k conv=fdatasync && rm -f test_$$
16384+0 Datensätze ein
16384+0 Datensätze aus
1073741824 bytes (1,1 GB, 1,0 GiB) copied, 9,1025 s, 118 MB/s
dd if=/dev/zero of=test_$$ bs=64k count=16k conv=fdatasync && rm -f test_$$
16384+0 Datensätze ein
16384+0 Datensätze aus
1073741824 bytes (1,1 GB, 1,0 GiB) copied, 20,2306 s, 53,1 MB/s

sudo hdparm -t /dev/nvme0n1

/dev/nvme0n1:
 HDIO_DRIVE_CMD(identify) failed: Inappropriate ioctl for device
 Timing buffered disk reads: 1194 MB in  3.58 seconds = 333.09 MB/sec

Startet mit 1.7GB/s und geht dann auf 118MB/s runter und das System bleibt während dessen auch hängen:

dd if=/dev/zero of=tempfile2 bs=4M count=4096 conv=fdatasync,notrunc status=progress
8061452288 bytes (8,1 GB, 7,5 GiB) copied, 68 s, 118 MB/s
1922+0 Datensätze ein
1922+0 Datensätze aus
8061452288 bytes (8,1 GB, 7,5 GiB) copied, 68,4321 s, 118 MB/s

 

[linrunner]

Hast Du schon mit einem älteren Kernel verglichen?

 

[tptux]

Ich vermute, dass trim nicht aktiv ist. Da gab es mal einen Bug von LUKS + LVM und trim. Schau mal die Mount-Options an.

 

[evidence]

Hast Du schon mit einem älteren Kernel verglichen?

ja, der 4.19.81-1-lts Kernel bringt ähnliche Ergebnisse:



Ich habe gestern nochmal etwas gegoogelt und festgestellt, dass mehrere Leute das Problem haben. "dmcrypt_write" hat volle Auslastung, daher sinkt die Schreibrate auch entsprechend.

https://wiki.archlinux.org/index.php/Improving_performance#Changing_I/O_scheduler

Habe ich testweise mal probiert, aber ohne Ergebnis!


cat /etc/fstab

# /dev/mapper/main-root
UUID=f066507b-e637-4fa9-860e-6dc5f8e048a2    /             ext4          rw,noatime,relatime    0 1

Trim ist nicht aktiviert. Laut https://wiki.archlinux.org/index.php/Solid_state_drive/NVMe#Discards brauch man es eigentlich auch nicht?

Habt ihr das denn aktiviert? Wenn ja "fstrim" oder "discard" ?


edit: https://wiki.archlinux.org/index.php/Solid_state_drive#Trim_an_entire_device "Change the value of issue_discards option from 0 to 1 in /etc/lvm/lvm.conf" ist wohl auch noch eine Option. Jetzt bin ich endgültig verwirrt

 

[tptux]

Zu ext4 kann ich nix sagen. Ich verwende hauptsächlich btrfs und dann kenne ich den Effekt auch. Meine Rechner-internen SSD werde mit der Option SSD eingehängt und die externen ohne diese Option. Wenn großen Mengen von intern auf extern kopiere, dann wird das immer langsamer. Andersherum, also von intern nach extern habe das nicht.

 

[ConiKost]

Hier hat jemand das selbe Problem (Leider ohne Lösung): https://forum.ubook.at/thread/3691-t470s-massenspeicher-512-gb-ssd-pcie-nvme/

 

[cuco]

Hier hat jemand das selbe Problem (Leider ohne Lösung): https://forum.ubook.at/thread/3691-t470s-massenspeicher-512-gb-ssd-pcie-nvme/

Naja, so wie ich das verstehe, beklagt er sich darüber, dass die Werte grundsätzlich nur bei ~400MB/s liegen, was an dem "eigenen" SSD-Modell von Lenovo oder auch an verschiedenen anderen Faktoren liegen kann - hier im Thread bricht die Geschwindigkeit aber ja erst nach einer Weile ein.

Zum Thema: Ja, TRIM bringt viel. Ich hatte eine SSD im Server mit ZFS und ZFSonLinux konnte bis vor kurzem kein TRIM. Die SSD fühlte sich nachher langsamer als eine Festplatte an. Einmal "blkdiscard" drüber laufen lassen (löscht einmal alles und führt TRIM aus), System neu aufgesetzt, danach war die Performance wieder ok. Dass man TRIM heute nicht mehr braucht, halte ich daher für falsch. Das Zitat aus dem Link im Arch-Wiki verstehe ich auch nicht so, dass man kein TRIM braucht, sondern so, dass man es nicht über die discard-Mount-Option (sondern per fstrim, z.B. per Cronjob o.ä.) durchführen sollte.

Die Option im LVM (issue_discards) auf 1 zu setzen schadet nicht, wird aber wohl nur aktiv, wenn du ein LV löschst oder verkleinerst. Für "normale" TRIM-Befehle seitens des Dateisystems ist das wohl nicht nötig, das funktioniert angeblich auch ohne die Option.

Wenn du LUKS/dm-crypt nutzt, musst du es aber "überzeugen", TRIM-Befehle durchzulassen: https://wiki.archlinux.org/index.ph...ard/TRIM_support_for_solid_state_drives_(SSD) Bin gerade erstaunt, wie viele Wege es inzwischen dafür gibt Bei mir war "damals" noch der Standardweg, "discard" in der /etc/crypttab anzuhängen.

Und dann fehlt halt noch das Dateisystem. Du kannst natürlich als Mount-Option in der /etc/fstab die Option "discard" mit anhängen. Ich habe damit noch nie negative Effekte gehabt, allerdings wird an sehr vielen Stellen davon abgeraten, daher nehme ich inzwischen auch die anderen Wege. Auf Ubuntu reicht ein "systemctl enable fstrim.timer", wenn ich diesen Link richtig verstehe: https://wiki.archlinux.org/index.php/Solid_state_drive#Periodic_TRIM funktioniert das auf Arch genau so. Dann wird wöchentlich ein TRIM ausgeführt. Für's erste Mal kannst du es auch mit "fstrim -v /" mal manuell anwerfen.

Danach sollte sich die Performance nicht sofort, aber doch recht bald wieder erholen.

 

[evidence]

Vielen Dank für eure Beiträge!

@cuco danke für deine Erläuterungen!

Ich habe jetzt folgendes umgesetzt:

grub.cfg:

cryptdevice=/dev/nvme0n1p2:main:allow-discards

Kernel Option:

rd.luks.options=discard

Zur Überprüfung "sudo cryptsetup status main"

/dev/mapper/main is active and is in use.
  type:    LUKS2
  cipher:  aes-xts-plain64
  keysize: 512 bits
  key location: keyring
  device:  /dev/nvme0n1p2
  sector size:  512
  offset:  32768 sectors
  size:    999131791 sectors
  mode:    read/write
  [B]flags:   discards[/B]

In "/etc/fstab" habe ich "discard" nicht als mount option hinzugefügt und lieber deinen Rat befolgt und "fstrimer" aktiviert. Einmal wöchentlich läuft das laut cron jetzt durch. Vorher habe ich "fstrimer" einmal manuell ausgeführt. Dabei wurde so einiges "getrimmt"^^. Ich habe jetzt schon den Eindruck, dass die Platte stabiler läuft. Werde das ganze jetzt mal beobachten bzw. mich in Geduld üben und meine Ergebnisse dann hier posten.

 

[mcb]

Stehe vor einem ähnlichen Problem: Wie überpfrüfe ich ob TRIM aktiv ist (Debian mit LUKS).

 

[cuco]

Debian mit LUKS ohne LVM?

Dann check' doch mal, ob "sudo cryptsetup status [LUKS-Volume-Name]" was von "discards" sagt oder ob derartiges in der /etc/crpyttab steht. Außerdem mal in die /etc/fstab gucken, ob die discard-Option drin ist oder ob der fstrim.timer aktiv ist ("systemctl status fstrim.timer").

Tipp: Standardmäßig wird beides ausgeschaltet sein, wenn du also nichts verändert hast, sind beide bzw. alle vier Checks vermutlich negativ.

 

[mcb]

Debian mit LUKS und LVM - auf den "Standarteinstellungen", benutzerdefinierte Partitionierung - Trim soll die Verschlüsselung "schwächen" habe ich mal gelesen, wahrscheinlich ist es deshalb bei Debian abgeschaltet.

- - - Beitrag zusammengeführt - - -

~# lsblk
NAME                MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
mmcblk0             179:0    0 183.4G  0 disk  
└─mmcblk0p1         179:1    0 183.3G  0 part  /media/marc/Card 2
nvme0n1             259:0    0   477G  0 disk  
├─nvme0n1p1         259:1    0   549M  0 part  
├─nvme0n1p2         259:2    0 224.5G  0 part  
├─nvme0n1p3         259:3    0   954M  0 part  /boot
├─nvme0n1p4         259:4    0     1K  0 part  
└─nvme0n1p5         259:5    0   251G  0 part  
  └─nvme0n1p5_crypt 254:0    0   251G  0 crypt 
    ├─vg-swap       254:1    0  11.5G  0 lvm   [SWAP]
    ├─vg-root       254:2    0  28.6G  0 lvm   /
    └─vg-home       254:3    0   211G  0 lvm   /home

Rest folgt.

- - - Beitrag zusammengeführt - - -

systemctl status fstrim.time
Unit fstrim.time.service could not be found.

Also ist es aus?

 

[linrunner]

Nein. Unit falsch geschrieben ...

 

[mcb]

So das habe ich jetzt gefunden: https://wiki.debian.org/SSDOptimization

Vertehe aber nicht mal die Hälfte ...

@linrunner: Unit habe ich gar nicht geschrieben, das wird ausgegeben nach: ~$ systemctl status fstrim.time

Oder hat sich dort auch der Fehlerteufel eingeschlichen?

 

[cuco]

Nicht das Wort "Unit" hast du falsch geschrieben, sondern die Unit (also den Namen der Unit). Vergleiche doch mal, was du schreibst, mit dem, was hier im Thread oder auch im verlinkten Artikel steht

Und ansonsten gilt für dich ziemlich das gleiche wie für den Threadersteller. fstrim.timer aktivieren (sofern noch nicht aktiv) und dem Crypto-Device erlauben, TRIM durchzureichen.

 

[mcb]

Oh wie peinlich ... :facepalm:

systemctl status fstrim.timer
● fstrim.timer - Discard unused blocks once a week
   Loaded: loaded (/lib/systemd/system/fstrim.timer; disabled; vendor preset: en
   Active: inactive (dead)
  Trigger: n/a
     Docs: man:fstrim

Das bedeutet es ist schon aktiv? Wird aber nicht durchgereicht?

- - - Beitrag zusammengeführt - - -

PS: den von mir verlinkten Artikel muß ich erstmal verstehen...

- - - Beitrag zusammengeführt - - -

"The "discard" options is not needed if your SSD has enough overprovisioning (spare space)"

- - - Beitrag zusammengeführt - - -

"The "discard" options with on-disk-cryptography (like dm-crypt) have drawbacks with security/cryptography."



- - - Beitrag zusammengeführt - - -

So hat die Hardware genug "spare space"

sudo smartctl -a /dev/nvme0
smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.19.0-6-amd64] (local build)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Number:                       WDC PC SN730 SDBQNTY-512G-1001
Serial Number:                      xXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Firmware Version:                   11110101
PCI Vendor/Subsystem ID:            0x15b7
IEEE OUI Identifier:                0x001b44
Total NVM Capacity:                 512,110,190,592 [512 GB]
Unallocated NVM Capacity:           0
Controller ID:                      8215
Number of Namespaces:               1
Namespace 1 Size/Capacity:          512,110,190,592 [512 GB]
Namespace 1 Formatted LBA Size:     512
Namespace 1 IEEE EUI-64:            001b44 8b44fad250
Local Time is:                      Fri Nov 22 21:23:01 2019 CET
Firmware Updates (0x14):            2 Slots, no Reset required
Optional Admin Commands (0x0017):   Security Format Frmw_DL Self_Test
Optional NVM Commands (0x005f):     Comp Wr_Unc DS_Mngmt Wr_Zero Sav/Sel_Feat Timestmp
Maximum Data Transfer Size:         128 Pages
Warning  Comp. Temp. Threshold:     84 Celsius
Critical Comp. Temp. Threshold:     88 Celsius
Namespace 1 Features (0x02):        NA_Fields

Supported Power States
St Op     Max   Active     Idle   RL RT WL WT  Ent_Lat  Ex_Lat
 0 +     5.50W       -        -    0  0  0  0        0       0
 1 +     3.50W       -        -    1  1  1  1        0       0
 2 +     3.00W       -        -    2  2  2  2        0       0
 3 -   0.0700W       -        -    3  3  3  3     4000   10000
 4 -   0.0025W       -        -    4  4  4  4     4000   40000

Supported LBA Sizes (NSID 0x1)
Id Fmt  Data  Metadt  Rel_Perf
 0 +     512       0         2
 1 -    4096       0         1

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

SMART/Health Information (NVMe Log 0x02, NSID 0xffffffff)
Critical Warning:                   0x00
Temperature:                        25 Celsius
[COLOR=#ff0000][B]Available Spare:                    100%
Available Spare Threshold:          10%
Percentage Used:                    0%[/B][/COLOR]
Data Units Read:                    3,500,951 [1.79 TB]
Data Units Written:                 2,343,791 [1.20 TB]
Host Read Commands:                 40,266,609
Host Write Commands:                25,848,462
Controller Busy Time:               54
Power Cycles:                       120
Power On Hours:                     45
Unsafe Shutdowns:                   53
Media and Data Integrity Errors:    0
Error Information Log Entries:      1
Warning  Comp. Temperature Time:    0
Critical Comp. Temperature Time:    0

Error Information (NVMe Log 0x01, max 256 entries)
No Errors Logged

Weil dann könnte ich mir den Aufwand ja sparen (soweit ich das im Artikel verstanden habe)?

Danke

 

[cuco]

Active: inactive (dead)

Das bedeutet es ist schon aktiv? Wird aber nicht durchgereicht?

Also "inactive" heißt in meinem Verständnis, dass es nicht aktiv ist

"The "discard" options is not needed if your SSD has enough overprovisioning (spare space)"

Das kann ich aus eigener Erfahrung definitiv nicht bestätigen bzw. sogar ganz klar widerlegen. Bei mir hat TRIM große Unterschiede in der Performance einer Samsung 970 Pro gemacht. Wobei man auch noch aufpassen muss, ob das "eigene" Overprovisioning gemeint ist (teil der SSD unpartioniert lassen) oder der Platz, den der SSD-Hersteller gleich reserviert hat.

"The "discard" options with on-disk-cryptography (like dm-crypt) have drawbacks with security/cryptography."

Joar, bei Attacken kann man halt sehen, welcher Platz belegt ist und welcher nicht. Damit kann man Attacken gezielter auf den belegten Platz anwenden, anstatt wild rumzuraten. Sofern die Verschlüsselung selbst sicher ist, ändert das aber nicht viel (bzw. nichts).

So hat die Hardware genug "spare space"

Ich bin mir nicht sicher, ob die nicht eher das "eigene" Overprovisioning meinen, das kann man an den SMART-Werten nicht sehen.

Weil dann könnte ich mir den Aufwand ja sparen (soweit ich das im Artikel verstanden habe)?

Meiner Meinung nach: Nein. Außerdem ist es nicht viel Aufwand. Füg die Discard-Option für dein Crypto-Device hinzu (da gibt's mehrere Wege, die hier im Thread schon verlinkt wurden) und dann aktiviere TRIM per "systemctl enable fstrim.timer". Ggf. noch einmal per Hand "Trimmen": "fstrim -v /".

 

[mcb]

Danke cuco,

ich werde das mal versuchen - wenn ich ein wenig Zeit habe - ist vielleicht nicht wirklich "schwer" das einzurichten, aber als nicht Informatiker steht man da ganz schnell dumm da wenn ein Fehler auftritt. (Ich weiß wovon ich rede )

 

[evidence]

Ich kann dir nur empfehlen die Trim-Funktion zu aktivieren. Ich dachte auch lange Zeit, dass das überflüssig sei (habe das irgendwo gelesen und lange Zeit in meinem Kopf so gespeichert gehabt), aber seitdem ich das aktiviert habe, hat sich die Performance deutlich gebessert. Ich hatte vorher auch immer mal wieder lange Wartezeiten bei der Initialisierung meines Desktopenviroments. Dabei nutze ich schon XFCE, was ja wirklich nicht sonderlich perfomancelastig ist.

Ich habe ja im Startpost ein paar Benchmarks gemacht und erreiche mittlerweile deutlich stabiler und höherer Schreibraten (Immer noch nicht konstant 1 gb/s, aber deutlich mehr als die zitierten 118 mb/s). Kopieren vom Server ist mittlerweile auch kein Problem mehr und der Laptop bleibt angenehm stabil ohne ständigen Freeze-Zustand. Habe es auf meinem Debian Homeserver auch direkt aktiviert. Du kannst dich an den geposteten Archwiki-Links orientieren. Da wird alles Wichtige erklärt und lässt sich auch ohne weiteres auf Debian übertragen.

Noch einmal Danke für die wertvolle Hilfestellung.

 

[mcb]

Ja, danke ich werde das umsetzen ... (hoffe es geht nichts schief - das bekäme ich nicht repariert )

 

[mcb]

So, ich habe das jetzt mal umgesetzt, könnten die Profies mal bitte drüberschauen?

sudo nano /etc/crypttab

nvme0n1p5_crypt UUID=c6ed8031-d40b-4243-b53b-dfac3036e775 none luks,[B]discard[/B]

systemctl status fstrim.timer
● fstrim.timer - Discard unused blocks once a week
   Loaded: loaded (/lib/systemd/system/fstrim.timer; enabled; vendor preset: enabled)
   Active: inactive (dead)
  Trigger: n/a
     Docs: man:fstrim

Habe fstrim dann aktiviert und zusätzlich gibt ein

sudo fstrim -v /
/: 83.8 MiB (87900160 bytes) trimmed

Danke

- - - Beitrag zusammengeführt - - -

Edit: Folgendes verstehe ich nicht.

root@MB:/home/marc# systemctl enable fstrim.timer
root@MB:/home/marc# systemctl status fstrim.timer
● fstrim.timer - Discard unused blocks once a week
   Loaded: loaded (/lib/systemd/system/fstrim.timer; enabled; vendor preset: enabled)
   Active: inactive (dead)
  Trigger: n/a
     Docs: man:fstrim

root@MB:/home/marc# systemctl enable fstrim.timer
root@MB:/home/marc# systemctl status fstrim.timer
● fstrim.timer - Discard unused blocks once a week
Loaded: loaded (/lib/systemd/system/fstrim.timer; enabled; vendor preset: enabled)
Active: inactive (dead)
Trigger: n/a
Docs: man:fstrim