Mir ist aufgefallen das die Leistung immer mehr sinkt.
Von Anfangs ca 1600 MB/s sind mittlerweile nur noch ca 1150 MB/s übrig.
Ich war der Meinung ext4 steht da drüber.
Ist das sonst noch jemand aufgefallen ?
Was kann man tun ?
Samsung SSD 950 Pro
Wie voll ist denn die SSD?
Ist diese Verschlüsselt oder wenn nicht, läuft regelmäßig mal ein TRIM durch?
Beobachtest du deine Beeinträchtigung nur beim lesen Und/oder Schreibzugriffe?
Was sagen denn die SMART-Werte dazu zwecks fehlerhaften Sektoren? Wenn der Wert regelmäßig höher wird, lässt sich zumindest einen Verschleiß der Zellen vermuten.
Aber auf Ext4 würde ich das nicht wirklich schieben, da sind eher andere Gründe warscheinlicher.
Wie hast Du die Schreib-/Leseleistung gemessen ?
unverschlüsselt
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-5.17.1-3-MANJARO] (local build)
Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Number: Samsung SSD 950 PRO 512GB
Serial Number: S2GMNX0H916107M
Firmware Version: 2B0QBXX7
PCI Vendor/Subsystem ID: 0x144d
IEEE OUI Identifier: 0x002538
Controller ID: 1
NVMe Version: <1.2
Number of Namespaces: 1
Namespace 1 Size/Capacity: 512.110.190.592 [512 GB]
Namespace 1 Utilization: 86.993.453.056 [86,9 GB]
Namespace 1 Formatted LBA Size: 512
Namespace 1 IEEE EUI-64: 002538 5961b09f5f
Local Time is: Sat Apr 23 20:10:16 2022 CEST
Firmware Updates (0x06): 3 Slots
Optional Admin Commands (0x0007): Security Format Frmw_DL
Optional NVM Commands (0x001f): Comp Wr_Unc DS_Mngmt Wr_Zero Sav/Sel_Feat
Log Page Attributes (0x01): S/H_per_NS
Maximum Data Transfer Size: 32 Pages
Supported Power States
St Op Max Active Idle RL RT WL WT Ent_Lat Ex_Lat
0 + 6.50W - - 0 0 0 0 5 5
1 + 5.80W - - 1 1 1 1 30 30
2 + 3.60W - - 2 2 2 2 100 100
3 - 0.0700W - - 3 3 3 3 500 5000
4 - 0.0050W - - 4 4 4 4 2000 22000
Supported LBA Sizes (NSID 0x1)
Id Fmt Data Metadt Rel_Perf
0 + 512 0 0
=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
SMART/Health Information (NVMe Log 0x02)
Critical Warning: 0x00
Temperature: 28 Celsius
Available Spare: 100%
Available Spare Threshold: 10%
Percentage Used: 1%
Data Units Read: 46.734.619 [23,9 TB]
Data Units Written: 32.421.796 [16,5 TB]
Host Read Commands: 622.126.787
Host Write Commands: 528.537.991
Controller Busy Time: 2.381
Power Cycles: 1.924
Power On Hours: 11.254
Unsafe Shutdowns: 70
Media and Data Integrity Errors: 0
Error Information Log Entries: 7.238
Error Information (NVMe Log 0x01, 16 of 64 entries)
Num ErrCount SQId CmdId Status PELoc LBA NSID VS
0 7238 0 0x201c 0x4004 0x000 0 0 -
1 7237 0 0x001d 0x4004 0x000 0 0 -
2 7236 0 0x1008 0x4004 0x000 0 0 -
3 7235 0 0x0009 0x4004 0x000 0 0 -
4 7234 0 0x201c 0x4004 0x000 0 0 -
5 7233 0 0x001d 0x4004 0x000 0 0 -
6 7232 0 0x1000 0x4004 0x000 0 0 -
7 7231 0 0x0001 0x4004 0x000 0 0 -
8 7230 0 0x1004 0x4004 0x000 0 0 -
9 7229 0 0x0005 0x4004 0x000 0 0 -
10 7228 0 0x1014 0x4004 0x000 0 0 -
11 7227 0 0x0015 0x4004 0x000 0 0 -
12 7226 0 0x1000 0x4004 0x000 0 0 -
13 7225 0 0x0001 0x4004 0x000 0 0 -
14 7224 0 0x1008 0x4004 0x000 0 0 -
15 7223 0 0x0009 0x4004 0x000 0 0 -
hdparm -t /dev/nvme0n1p4 ✔
/dev/nvme0n1p4:
Timing buffered disk reads: 3524 MB in 3.00 seconds = 1174.45 MB/sec
kernel, mainboard, bioseinstellungen ? gibt ne menge andere mögliche fehlerquellen. wie alt ist deine 950Pro? immerhin hat sie schon 11.254 Betriebsstunden hinter sich, wurde aber nicht so geknechtet wie meine, die weit weniger betriebsstunden hat. der datendurchsatz ist allerdings schon sehr niedrig, mal zum vergleich meine 970Pro, die ist so aus 2018:
was noch zu erwähnen ist das ich ein intel-system nutze, das maximal 4000MB/sec (4GB/sec) hat, den müssen sich aber alle hardwarekomponenten teilen, die 2,6 GB/sec sind also schon mal recht gut in dem Fall.
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-5.15.32-1-MANJARO] (local build)
Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Number: Samsung SSD 970 PRO 512GB
Serial Number: S463NF0KA20400M
Firmware Version: 1B2QEXP7
PCI Vendor/Subsystem ID: 0x144d
IEEE OUI Identifier: 0x002538
Total NVM Capacity: 512.110.190.592 [512 GB]
Unallocated NVM Capacity: 0
Controller ID: 4
NVMe Version: 1.3
Number of Namespaces: 1
Namespace 1 Size/Capacity: 512.110.190.592 [512 GB]
Namespace 1 Utilization: 52.074.315.776 [52,0 GB]
Namespace 1 Formatted LBA Size: 512
Namespace 1 IEEE EUI-64: 002538 5a81b04fb0
Local Time is: Sat Apr 23 20:26:57 2022 CEST
Firmware Updates (0x16): 3 Slots, no Reset required
Optional Admin Commands (0x0037): Security Format Frmw_DL Self_Test Directvs
Optional NVM Commands (0x005f): Comp Wr_Unc DS_Mngmt Wr_Zero Sav/Sel_Feat Timestmp
Log Page Attributes (0x03): S/H_per_NS Cmd_Eff_Lg
Maximum Data Transfer Size: 512 Pages
Warning Comp. Temp. Threshold: 81 Celsius
Critical Comp. Temp. Threshold: 81 Celsius
Supported Power States
St Op Max Active Idle RL RT WL WT Ent_Lat Ex_Lat
0 + 6.20W - - 0 0 0 0 0 0
1 + 4.30W - - 1 1 1 1 0 0
2 + 2.10W - - 2 2 2 2 0 0
3 - 0.0400W - - 3 3 3 3 210 1200
4 - 0.0050W - - 4 4 4 4 2000 8000
Supported LBA Sizes (NSID 0x1)
Id Fmt Data Metadt Rel_Perf
0 + 512 0 0
=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
SMART/Health Information (NVMe Log 0x02)
Critical Warning: 0x00
Temperature: 44 Celsius
Available Spare: 100%
Available Spare Threshold: 10%
Percentage Used: 0%
Data Units Read: 86.879.846 [44,4 TB]
Data Units Written: 18.320.462 [9,38 TB]
Host Read Commands: 280.707.265
Host Write Commands: 1.963.102.959
Controller Busy Time: 1.114
Power Cycles: 2.985
Power On Hours: 3.660
Unsafe Shutdowns: 366
Media and Data Integrity Errors: 0
Error Information Log Entries: 928
Warning Comp. Temperature Time: 0
Critical Comp. Temperature Time: 0
Temperature Sensor 1: 44 Celsius
Temperature Sensor 2: 43 Celsius
Error Information (NVMe Log 0x01, 16 of 64 entries)
Num ErrCount SQId CmdId Status PELoc LBA NSID VS
0 928 0 0x1012 0x4004 - 0 0 -
/dev/nvme0n1:
Timing buffered disk reads: 8054 MB in 3.00 seconds = 2684.51 MB/sec
Am Bios etc wurde ja nichts geändert.
Bei der Installation von Manjaro hatte ich 1600 MB/s und mittlerweile 1100 MB/s
Die Installation ist jetzt ca 1 Jahr alt.
kannst du mal mit inxi posten was das für ein system ist und was alles an hardware existiert. wie gesagt bei intel ist der hahnenfuß das (mal ausgenommen die aktuellsten cpu’s) der interne bus in der CPU mit seinen max. 4GB/sec ein system aushebeln/beschränken kann wenn sich zum bsp. zuviel hardware den teilen muss. das nächste wäre der kernel, gefühlt wird der seit 5.10 immer langsamer (meine persönliche meinung/empfindung).
inxi -Fz ✔
System:
Kernel: 5.17.1-3-MANJARO arch: x86_64 bits: 64 Desktop: KDE Plasma
v: 5.24.4 Distro: Manjaro Linux
Machine:
Type: Desktop Mobo: ASUSTeK model: Rampage III Extreme v: Rev 1.xx
serial: <superuser required> BIOS: American Megatrends v: 1601
date: 01/03/2012
CPU:
Info: 6-core model: Intel Core i7 X 980 bits: 64 type: MT MCP cache:
L2: 1.5 MiB
Speed (MHz): avg: 3370 min/max: N/A cores: 1: 1797 2: 3513 3: 3513
4: 3513 5: 3513 6: 3513 7: 3513 8: 3513 9: 3513 10: 3513 11: 3513 12: 3513
Graphics:
Device-1: NVIDIA GA104 [GeForce RTX 3070 Lite Hash Rate] driver: nvidia
v: 510.60.02
Display: x11 server: X.Org v: 1.21.1.3 driver: X: loaded: nvidia
gpu: nvidia,nvidia-nvswitch resolution: 2560x1440
OpenGL: renderer: NVIDIA GeForce RTX 3070/PCIe/SSE2
v: 4.6.0 NVIDIA 510.60.02
Audio:
Device-1: Intel 82801JI HD Audio driver: snd_hda_intel
Device-2: NVIDIA GA104 High Definition Audio driver: snd_hda_intel
Sound Server-1: ALSA v: k5.17.1-3-MANJARO running: yes
Sound Server-2: PipeWire v: 0.3.49 running: yes
Network:
Device-1: Intel 82567V-2 Gigabit Network driver: e1000e
IF: enp0s25 state: up speed: 1000 Mbps duplex: full mac: <filter>
Bluetooth:
Device-1: ASUSTek ASUS USB-BT500 type: USB driver: btusb
Report: rfkill ID: hci0 state: up address: see --recommends
Device-2: Cambridge Silicon Radio Bluetooth Dongle (HCI mode) type: USB
driver: N/A
Report: This feature requires one of these tools: hciconfig/bt-adapter
Drives:
Local Storage: total: 23.21 TiB used: 6.19 TiB (26.7%)
ID-1: /dev/nvme0n1 vendor: Samsung model: SSD 950 PRO 512GB
size: 476.94 GiB
ID-2: /dev/sda vendor: Samsung model: SSD 870 EVO 1TB size: 931.51 GiB
ID-3: /dev/sdb vendor: Samsung model: SSD 870 EVO 2TB size: 1.82 TiB
ID-4: /dev/sdc vendor: Seagate model: ST3000NM0033-9ZM178 size: 2.73 TiB
ID-5: /dev/sdd vendor: Seagate model: ST3000NM0033-9ZM178 size: 2.73 TiB
ID-6: /dev/sde vendor: Seagate model: ST16000NM001G-2KK103
size: 14.55 TiB
Partition:
ID-1: / size: 287.23 GiB used: 18.47 GiB (6.4%) fs: ext4
dev: /dev/nvme0n1p4
Swap:
Alert: No swap data was found.
Sensors:
System Temperatures: cpu: 22.0 C mobo: 32.0 C gpu: nvidia temp: 43 C
Fan Speeds (RPM): cpu: 1335 gpu: nvidia fan: 0%
Info:
Processes: 320 Uptime: 1h 51m Memory: 11.68 GiB used: 3.22 GiB (27.6%)
Shell: Zsh inxi: 3.3.15
Das es eventuell am Kernel liegt. hmm könnte sein.
kannst es ja mal mit einem anderen kernel ausprobieren, aber hallo, du hast glatt 6 (!) Platten verbaut, respekt da wundert es mich nicht das dein rechner ins schwitzen kommt. schon mal an ein nas gedacht, vielleicht sogar mit 10 GB/s ? gut aktuell noch etwas teuer aber langsam geht es auch da in bezahlbare regionen. oder ein nas mit mehreren netzwerkkarten die du mit nic-bonding zu einem netz bündelst ? das bei 6 Platten der kernel erstmal werkeln muss und die bandbreite sinkt wundert mich nicht. trotzdem ist deine samsung pro trotzdem ein bisschen langsam. wie alt ist die denn und was hat die nominell für lese- und schreibraten die samsung angegeben hat ?
ich kann ja mal mit w10 messen
Also die windoof Partition kommt auf 1650 MB/s
An der Hardware liegt es nicht !
interessantes thema, obwohl ich mir vorher noch nicht soviel gedanken gemacht habe. hab mal ein wenig gegoogelt, wenn unter linux das power-management für ssd/nvme aktiv ist, dann wird die platte eingebremst. werde mir die tage selbst mal anschauen was man da rauskitzeln kann. vielleicht hilft dir der wiki-beitrag ja ein wenig um weiter zu kommen.
https://wiki.archlinux.org/title/Solid_state_drive/NVMe#Power_Saving_(APST)
Wann wurde die SSD zum letzten Mal getrimmt ?
systemctl status fstrim.timer
Dann auch mal mit hdparm direkt auf die SSD zugreifen.
Dann auch hdparm -i /dev/... und mit smartmontools den Status der SSD auslesen.
Das wäre auch interessant:
sudo tune2fs -l /dev/nvme0n1p4
Na aber gerne doch, euer Wunsch ist mir Befehl
tune2fs 1.46.5 (30-Dec-2021)
Filesystem volume name: System
Last mounted on: /
Filesystem UUID: 9929717f-a7bf-4f29-bc5e-6b7f603d689f
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 19202048
Block count: 76779846
Reserved block count: 3838992
Overhead clusters: 1483952
Free blocks: 70157004
Free inodes: 18796710
First block: 0
Block size: 4096
Fragment size: 4096
Group descriptor size: 64
Reserved GDT blocks: 1024
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
Flex block group size: 16
Filesystem created: Thu Sep 16 21:17:26 2021
Last mount time: Mon Apr 25 22:55:44 2022
Last write time: Mon Apr 25 22:55:44 2022
Mount count: 543
Maximum mount count: -1
Last checked: Thu Sep 16 21:18:11 2021
Check interval: 0 (<none>)
Lifetime writes: 1090 GB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 32
Desired extra isize: 32
Journal inode: 8
First orphan inode: 12058717
Default directory hash: half_md4
Directory Hash Seed: 6c76adf2-8d3f-4926-a42d-385a816a8219
Journal backup: inode blocks
Checksum type: crc32c
Checksum: 0x78b6f3c5
systemctl status fstrim.timer
● fstrim.timer - Discard unused blocks once a week
Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled; vendor preset: disabled)
Active: active (waiting) since Mon 2022-04-25 22:55:45 CEST; 15min ago
Until: Mon 2022-04-25 22:55:45 CEST; 15min ago
Trigger: Mon 2022-05-02 01:16:23 CEST; 6 days left
Triggers: ● fstrim.service
Docs: man:fstrim
Apr 25 22:55:45 weingeist-PC systemd[1]: Started Discard unused blocks once a week.
hdparm -i /dev/nvme0n1p4
/dev/nvme0n1p4:
HDIO_GET_IDENTITY failed: Inappropriate ioctl for device
hdparm -Tt --direct /dev/nvme0n1p4
/dev/nvme0n1p4:
Timing O_DIRECT cached reads: 2250 MB in 2.00 seconds = 1125.15 MB/sec
Timing O_DIRECT disk reads: 4248 MB in 3.00 seconds = 1415.52 MB/sec
fast_commit ist hier nicht aktiv, sollte auf NVMEs einen deutlichen Performance-Zugewinn erlauben.
1TB innerhalb eines Jahres. Das geht ja noch.
Interessant wäre auch noch, die Fragmentierungsrate:
# Hier nichts defragmentiert, solange `-c` angeben wird.
sudo e4defrag -c /
und welcher Scheduler verwendet wird:
grep "" /sys/block/*/queue/scheduler
Auf NVMEs sollte generell keiner verwendet werden, also none, weil diese generell ausbremsen bei diesen.
e4defrag 1.46.5 (30-Dec-2021)
<Fragmented files> now/best size/ext
1. /home/weingeist/.local/share/Steam/logs/bootstrap_log.txt
15/1 4 KB
2. /home/weingeist/.local/share/Steam/logs/systemmanager.txt
13/1 4 KB
3. /home/weingeist/.local/share/Steam/installscriptevalutor_log.txt
12/1 4 KB
4. /home/weingeist/.local/share/Steam/logs/steamui_system.txt
11/1 4 KB
5. /home/weingeist/.local/share/qBittorrent/logs/qbittorrent.log
11/1 4 KB
Total/best extents 352423/345215
Average size per extent 64 KB
Fragmentation score 1
grep "" /sys/block/*/queue/scheduler ✔ 7s
/sys/block/loop0/queue/scheduler:[none] mq-deadline kyber bfq
/sys/block/loop1/queue/scheduler:[none] mq-deadline kyber bfq
/sys/block/loop2/queue/scheduler:[none] mq-deadline kyber bfq
/sys/block/loop3/queue/scheduler:[none] mq-deadline kyber bfq
/sys/block/loop4/queue/scheduler:[none] mq-deadline kyber bfq
/sys/block/loop5/queue/scheduler:[none] mq-deadline kyber bfq
/sys/block/loop6/queue/scheduler:[none] mq-deadline kyber bfq
/sys/block/loop7/queue/scheduler:[none] mq-deadline kyber bfq
/sys/block/nvme0n1/queue/scheduler:[none] mq-deadline kyber bfq
/sys/block/sda/queue/scheduler:[mq-deadline] kyber bfq none
/sys/block/sdb/queue/scheduler:[mq-deadline] kyber bfq none
/sys/block/sdc/queue/scheduler:[mq-deadline] kyber bfq none
/sys/block/sdd/queue/scheduler:[mq-deadline] kyber bfq none
/sys/block/sde/queue/scheduler:[mq-deadline] kyber bfq none
Mal schauen wie man das fast_commit aktiviert
Edit: gefunden tune2fs -O fast_commit /dev/drivepartition
Hat aber nichts gebracht
Es könnte sein, daß die SSD defekt ist.
Was ergibt denn das Ausführen von smartmoontools (als root) ?
kaputt ist die nicht, null kritische warnungen und die errorlogs sind vergleichsweise niedrig. ich tippe eher darauf das der kernel ins schwitzen kommt weil ja 6 Festplatten installiert sind und das vom system verwaltet werden muss. das bios ist von 2012, der rechner hat also auch schon ein paar jahre auf dem buckel und die technik ist demenstsprechend auch nicht mehr state of the art. modernere rechner haben da schnellere festplattencontroller und bieten höheren datendurchsatz.
vielleicht oder wahrscheinlich lässt sich da noch etwas rauskitzeln wenn man mit den cache-einstellungen und dem synchronisieren der platten “spielt”. leider gibt es im arch-wiki nichts darüber, zumindest habe ich nichts gefunden. man findet im netz einige anleitungen und tipps, wie man das syncing und den cache konfigurieren kann um einen höheren datendurchsatz zu erreichen. manches scheint mit der heißen stricknadel gestrickt zu sein aber versuch macht kluch.
Welche Hardware wird verwendet ? inxi -Fza