[gelöst] System durch Festplatte zu langsam?

Hast Du Probleme mit Hardware, die durch die anderen Foren nicht abgedeckt werden? Schau auch in den "Tipps und Tricks"-Bereich.
buhtz
Beiträge: 1099
Registriert: 04.12.2015 17:54:49
Kontaktdaten:

[gelöst] System durch Festplatte zu langsam?

Beitrag von buhtz » 19.02.2018 22:15:10

Ich beobachte seit Monaten ein merkwürdiges Verhalten und möchte dem jetzt doch mal auf den Grund gehen. Es geht um ein 2-Core System mit 8 GB RAM. Also nicht zu langsam. Darauf läuft XFCE mit allerhand hübschen Hardware-Statusanzeigen in der Taskleiste.

Dabei kann ich erkennen, dass sehr häufig das System lahmt oder sogar nahezu einfriert, wenn von der Platte gelesen wird. Das scheint lange zu dauern. Das ist merkbar beim Booten (reicht zum Kaffeekochen) oder start großer Anwendungen (Firefox, LibreOffice).

Die HDD ist tatsächlich etwas älter als der Rest der Hardware, aber nicht "alt". ;) Hatte schon viel ältere sehr viel länger laufen. Ob sie am Anfang noch gut ging, kann ich nicht mehr sicher aus meiner Erinnerung sagen.
Die SMART-Werte sehen, soweit ich das interpretieren kann, aber gut aus. (siehe unten)

Geräusche macht sie auch nicht. Das System selbst ist sehr leise. Aber die Platte ist eigentlich nie zu hören - steht aber direkt neben dem Monitor im Slim-Gehäuse.

Welche Möglichkeiten unter Debian unstable hätte ich nun, hier weiter Diagnose zu betreiben? Vielleicht ist ja auch nur irgendeine Treibereinstellung ineffizient oder so?
Gibt es so ne Art Festplattentestprogramm (wie von der c't leider nur für Windows), wo man hübsche Werte bekommt, die man mal vergleichen könnte?

Platten tauschen ist mir derzeit zu viel Aufwand. Neue SSD kaufen gibt mein Budget nicht her.

Code: Alles auswählen

smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.15.3-towo.1-siduction-amd64] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Western Digital Caviar Green (AF)
Device Model:     WDC WD20EARS-00S8B1
Serial Number:    WD-WCAVY4333133
LU WWN Device Id: 5 0014ee 2049ff22c
Firmware Version: 80.00A80
User Capacity:    2.000.398.934.016 bytes [2,00 TB]
Sector Size:      512 bytes logical/physical
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ATA8-ACS (minor revision not indicated)
SATA Version is:  SATA 2.6, 3.0 Gb/s
Local Time is:    Mon Feb 19 22:16:04 2018 CET
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:  (0x84)	Offline data collection activity
					was suspended by an interrupting command from host.
					Auto Offline Data Collection: Enabled.
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: 		(40800) 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: 	 ( 464) minutes.
Conveyance self-test routine
recommended polling time: 	 (   5) minutes.
SCT capabilities: 	       (0x3031)	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   200   200   051    Pre-fail  Always       -       0
  3 Spin_Up_Time            0x0027   147   138   021    Pre-fail  Always       -       9641
  4 Start_Stop_Count        0x0032   097   097   000    Old_age   Always       -       3134
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x002e   100   253   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   082   082   000    Old_age   Always       -       13264
 10 Spin_Retry_Count        0x0032   100   100   000    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   100   100   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   097   097   000    Old_age   Always       -       3008
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       99
193 Load_Cycle_Count        0x0032   084   084   000    Old_age   Always       -       348301
194 Temperature_Celsius     0x0022   115   106   000    Old_age   Always       -       37
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   200   200   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   200   200   000    Old_age   Offline      -       0

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Conveyance offline  Completed without error       00%      8694         -
# 2  Short offline       Completed without error       00%      7928         -
# 3  Short offline       Completed without error       00%      7923         -
# 4  Short offline       Completed without error       00%      7897         -
# 5  Short offline       Completed without error       00%      7893         -
# 6  Short offline       Completed without error       00%      7865         -
# 7  Short offline       Completed without error       00%      7837         -
# 8  Short offline       Completed without error       00%      7826         -
# 9  Short offline       Completed without error       00%      7815         -
#10  Short offline       Completed without error       00%      7809         -
#11  Short offline       Completed without error       00%      7803         -
#12  Short offline       Completed without error       00%      7799         -
#13  Short offline       Completed without error       00%      7793         -
#14  Short offline       Completed without error       00%      7774         -
#15  Short offline       Completed without error       00%      7746         -
#16  Short offline       Completed without error       00%      7733         -
#17  Short offline       Completed without error       00%      7728         -
#18  Short offline       Completed without error       00%      7666         -
#19  Short offline       Completed without error       00%      7653         -
#20  Short offline       Completed without error       00%      7630         -
#21  Short offline       Completed without error       00%      7622         -

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.
Zuletzt geändert von buhtz am 16.10.2018 22:58:38, insgesamt 1-mal geändert.
Debian 11 & 12; Desktop-PC, Headless-NAS, Raspberry Pi 4
Teil des Upstream Betreuer Teams von Back In Time (Debianbackintime)

DeletedUserReAsG

Re: System durch Festplatte zu langsam?

Beitrag von DeletedUserReAsG » 19.02.2018 22:20:19

Für Benchmarks wäre bonnie++ brauchbar; um zu gucken, wo genau es hängt, kann iotop helfen.

buhtz
Beiträge: 1099
Registriert: 04.12.2015 17:54:49
Kontaktdaten:

Re: System durch Festplatte zu langsam?

Beitrag von buhtz » 19.02.2018 22:45:08

Mhm... Sieht interessant aus. Wie interpretiere ich das? Am besten mit einem Vergleich? Was liefern eure HDD-Systeme für Zahlen?

Code: Alles auswählen

$ sudo bonnie++ -u user -d /tmp/bonnie
[sudo] Passwort für user: 
Using uid:1000, gid:1000.
Writing a byte at a time...done
Writing intelligently...done
Rewriting...done
Reading a byte at a time...done
Reading intelligently...done
start 'em...done...done...done...done...done...
Create files in sequential order...done.
Stat files in sequential order...done.
Delete files in sequential order...done.
Create files in random order...done.
Stat files in random order...done.
Delete files in random order...done.
Version  1.97       ------Sequential Output------ --Sequential Input- --Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
TONNE        15616M   926  97 95324   5 42760   3  2232  92 103195   3 266.1   4
Latency              9837us     395ms     429ms   24944us     190ms    2023ms
Version  1.97       ------Sequential Create------ --------Random Create--------
TONNE               -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++
Latency              4813us     461us     406us      86us      11us     205us
1.97,1.97,TONNE,1,1519077789,15616M,,926,97,95324,5,42760,3,2232,92,103195,3,266.1,4,16,,,,,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,9837us,395ms,429ms,24944us,190ms,2023ms,4813us,461us,406us,86us,11us,205us
Debian 11 & 12; Desktop-PC, Headless-NAS, Raspberry Pi 4
Teil des Upstream Betreuer Teams von Back In Time (Debianbackintime)

NAB
Beiträge: 5501
Registriert: 06.03.2011 16:02:23
Lizenz eigener Beiträge: MIT Lizenz

Re: System durch Festplatte zu langsam?

Beitrag von NAB » 20.02.2018 01:06:29

Hast du mal in die Ausgabe von
dmesg
geguckt? Hänger von Minuten sollten sich da eigentlich irgendwie niederschlagen.

Deine Platte hat schon 348301 mal ihre Köpfe geparkt (Load_Cycle_Count) und ist 13264 Stunden gelaufen, das wären 26 Parkvorgänge pro Stunde. Allerdings hat sie auch 3623 Stunden (13264 - 9641) mit geparkten Köpfen geschlafen. Schwer zu sagen, ob das bei deinem Nutzungsverhalten "normal" ist.

Die WD Green Platten übertreiben hier etwas mit dem Köpfe-Parken, das Thema wird öfter diskutiert:
https://www.gamingonlinux.com/articles/ ... 814/page=3
Das Wiederaufwecken der Platte dauert aber auch nur Sekunden, keine Minuten. Ich denke nicht, dass das hier zutrifft.
Never change a broken system. It could be worse afterwards.

"No computer system can be absolutely secure." Intel Document Number: 336983-001

buhtz
Beiträge: 1099
Registriert: 04.12.2015 17:54:49
Kontaktdaten:

Re: System durch Festplatte zu langsam?

Beitrag von buhtz » 20.02.2018 14:31:47

Mit dmesg werde ich mich beschäftigen...
NAB hat geschrieben: ↑ zum Beitrag ↑
20.02.2018 01:06:29
Deine Platte hat schon 348301 mal ihre Köpfe geparkt (Load_Cycle_Count) und ist 13264 Stunden gelaufen, das wären 26 Parkvorgänge pro Stunde. Allerdings hat sie auch 3623 Stunden (13264 - 9641) mit geparkten Köpfen geschlafen. Schwer zu sagen, ob das bei deinem Nutzungsverhalten "normal" ist.
Hey, danke für die tolle Interpretation! Sowas vermisse ich immer noch als GUI, auch wenn ich weiß, dass nicht alle Werte so adäquat interpretierbar sind, weil das häufig herstellerspezifisch ist.

Die Platte war früher mal in einem NAS. War aber ein Home-NAS mit wenigen Stunden Laufzeit am Tag, nie mehr als zwei User, die mal Musik/FIlme ziehen oder ein Backup machen. Nutzungsverhalten kommt also auch mehr einem Desktop als einem Server nah.
Die WD Green Platten übertreiben hier etwas mit dem Köpfe-Parken
Das geh ich auch mal an. Verglichen mit den dortigen Werten erscheint mir mein 348.301 Load_Cylce_Count in Relation zu den 13.264 Stunden Laufzeit auch sehr hoch. Was haben den eure Systeme da so?

Nebenfrage: Bei so einem hohen Load_Cycle_Count könnte die Platte also demnächst schon plötzlich hops gehen? Es wäre also kein langsamer Tod mit Vorwarnung? ;) Ich wollte das System mit einer zusätzlichen mSATA (~100 €) bestücken. Vielleicht spare ich mir das lieber und investiere gleich in eine dicke SSD? Ich brauche schon meine 1TB im System. Als SSD ist das teuer. Aber ich habe keinen Platz im SlimGehäuse für eine SSD und eine 3,5" HDD.
Debian 11 & 12; Desktop-PC, Headless-NAS, Raspberry Pi 4
Teil des Upstream Betreuer Teams von Back In Time (Debianbackintime)

Alternativende
Beiträge: 2090
Registriert: 07.07.2006 18:32:05

Re: System durch Festplatte zu langsam?

Beitrag von Alternativende » 20.02.2018 15:40:47

Hallo,
ich hatte mit einer Caviar Green (bei mir 1TB) auch schon mal ähnlichen Ärger. Das ganze System war unglaublich zäh, bei jeglichen Schreibarbeiten auf der Platte lahmte quasi alles. Bei mir war es nur eine Datenplatte, das OS war auf einer SSD und dennoch war es nicht auszuhalten.

Ich habe die Platte getauscht und seitdem Ruhe. Ich kann Dir nur meine Erfahrung beschreiben in diesem Kontext.

NAB
Beiträge: 5501
Registriert: 06.03.2011 16:02:23
Lizenz eigener Beiträge: MIT Lizenz

Re: System durch Festplatte zu langsam?

Beitrag von NAB » 20.02.2018 19:38:46

buhtz hat geschrieben: ↑ zum Beitrag ↑
20.02.2018 14:31:47
Das geh ich auch mal an. Verglichen mit den dortigen Werten erscheint mir mein 348.301 Load_Cylce_Count in Relation zu den 13.264 Stunden Laufzeit auch sehr hoch.
Das sehe ich anders. Ich wollte keine Panik machen. In dem Link erzählt er was von einem Parkvorgang alle 8 Sekunden und hat 2 Mio Parkvorgänge. Bei dir sind die Werte wesentlich freundlicher.
buhtz hat geschrieben: ↑ zum Beitrag ↑
20.02.2018 14:31:47
Was haben den eure Systeme da so?
Wenn "WD Green" draufsteht, kaufe ich es nicht.
buhtz hat geschrieben: ↑ zum Beitrag ↑
20.02.2018 14:31:47
Ich wollte das System mit einer zusätzlichen mSATA (~100 €) bestücken. Vielleicht spare ich mir das lieber und investiere gleich in eine dicke SSD? Ich brauche schon meine 1TB im System. Als SSD ist das teuer. Aber ich habe keinen Platz im SlimGehäuse für eine SSD und eine 3,5" HDD.
Ich sehe keinen Grund, HDDs generell zu meiden. Wie wär's mit ner WD Red und einer 128 MB mSATA?

Wobei ich deine WD Green auch nicht im Sterben sehe. Du fragtest nach der Ursache für dein langsames System. Deine HDD sieht eigentlich noch ganz gut aus.
Never change a broken system. It could be worse afterwards.

"No computer system can be absolutely secure." Intel Document Number: 336983-001

buhtz
Beiträge: 1099
Registriert: 04.12.2015 17:54:49
Kontaktdaten:

Re: System durch Festplatte zu langsam?

Beitrag von buhtz » 20.02.2018 21:50:24

Tatsächlich war der Idle3 timer auf 80 sec. Hab ihn deaktiviert. Wie ihr erwartet hattet, ändert das nichts am Verhalten. Hab die Bootzeit mal genauer gemessen. Dauert mit und ohne Idle3 ca 3 min 5 sec (1 min 10 sec bis X anspringt; 2 min 40 sec bis xfce mein Desktop-Hintergrundbild anzeigt; 3 min 5 sec bis im xfce-panel keine Lese-Aktivität auf der Festplatte mehr angezeigt wird).

Nebenbefund von meinem NAS:
Dort ist u. a. eine WD Red (WDC WD40EFRX-68WT0N0) drin bei der ebenfalls der Idle3-timer auf 80 stand.

Code: Alles auswählen

  9 Power_On_Hours          0x0032   088   088   000    Old_age   Always       -       9445
193 Load_Cycle_Count        0x0032   124   124   000    Old_age   Always       -       229714
Daneben (weil RAID1) eine Samsung gleichen Alters.

Code: Alles auswählen

  1 Raw_Read_Error_Rate     0x000f   118   099   006    Pre-fail  Always       -       191394976
  7 Seek_Error_Rate         0x000f   078   060   030    Pre-fail  Always       -       17421210523
  9 Power_On_Hours          0x0032   090   090   000    Old_age   Always       -       9424
193 Load_Cycle_Count        0x0032   099   099   000    Old_age   Always       -       2921
Zu Debiandmesg: Da weiß ich nicht so wirklich was ich damit anfangen soll. Verstehe die Meldungen nicht und weiß auch nicht zu welchem Zeitpunkt ich diese am besten lesen sollte. Hab mit dem Tool keine Erfahrung.
Debian 11 & 12; Desktop-PC, Headless-NAS, Raspberry Pi 4
Teil des Upstream Betreuer Teams von Back In Time (Debianbackintime)

NAB
Beiträge: 5501
Registriert: 06.03.2011 16:02:23
Lizenz eigener Beiträge: MIT Lizenz

Re: System durch Festplatte zu langsam?

Beitrag von NAB » 20.02.2018 23:48:45

buhtz hat geschrieben: ↑ zum Beitrag ↑
20.02.2018 21:50:24
Zu Debiandmesg: Da weiß ich nicht so wirklich was ich damit anfangen soll. Verstehe die Meldungen nicht und weiß auch nicht zu welchem Zeitpunkt ich diese am besten lesen sollte. Hab mit dem Tool keine Erfahrung.
dmesg zeigt dir einfach alle hardware-spezifischen Meldungen seit dem Booten an, die der Kernel für erwähnenswert hält. Wenn dir da kein dickes rotes "Error", "Hang" oder "Timeout" ins Auge fällt, wird da auch nichts zu finden sein.
Am Anfang jeder Zeile stehen Zeitangaben in Millisekunden seit dem Booten. Mit
dmesg -T
zeigt er dir Minuten und Sekunden ... da du die schon so grob bestimmt hast, fällt dir die zeitliche Orientierung so vielleicht leichter.

Und was völlig anderes: Was sagt eigentlich

Code: Alles auswählen

hdparm -tT /dev/sda1
? (laut man hdparm soll man das mehrmals wiederholen)
Never change a broken system. It could be worse afterwards.

"No computer system can be absolutely secure." Intel Document Number: 336983-001

buhtz
Beiträge: 1099
Registriert: 04.12.2015 17:54:49
Kontaktdaten:

Re: System durch Festplatte zu langsam?

Beitrag von buhtz » 21.02.2018 13:40:56

Debiandmesg zeigt nichts Auffälliges nach dem Booten.
NAB hat geschrieben: ↑ zum Beitrag ↑
20.02.2018 23:48:45
Was sagt eigentlich

Code: Alles auswählen

hdparm -tT /dev/sda1
? (laut man hdparm soll man das mehrmals wiederholen)

Code: Alles auswählen

$for x in {1..3}; do sudo hdparm -tT /dev/sda1; done

/dev/sda1:
 Timing cached reads:   14872 MB in  2.00 seconds = 7452.50 MB/sec
 Timing buffered disk reads: 310 MB in  3.01 seconds = 103.13 MB/sec

/dev/sda1:
 Timing cached reads:   15004 MB in  2.00 seconds = 7519.48 MB/sec
 Timing buffered disk reads: 310 MB in  3.01 seconds = 102.85 MB/sec

/dev/sda1:
 Timing cached reads:   14162 MB in  2.00 seconds = 7096.51 MB/sec
 Timing buffered disk reads: 310 MB in  3.00 seconds = 103.22 MB/sec
Debian 11 & 12; Desktop-PC, Headless-NAS, Raspberry Pi 4
Teil des Upstream Betreuer Teams von Back In Time (Debianbackintime)

NAB
Beiträge: 5501
Registriert: 06.03.2011 16:02:23
Lizenz eigener Beiträge: MIT Lizenz

Re: System durch Festplatte zu langsam?

Beitrag von NAB » 21.02.2018 16:44:04

100 MB/s ist nun nicht rasend schnell ... schnellste mechanische Platten erreichen da 250 MB/s. Aber weißt du ... selbst wenn sie 200 MB/s schaffen würde, auch dann wäre es "nur" doppelt so schnell. Dann reicht's beim Booten noch für nen halben Kaffee, das ist immer noch "langsam".

Hast du beim Starten von z.B. Firefox die CPU-Auslastung im Blick? Wie eng ist es denn da?

Und wenn du Firefox beendest und ein zweites mal startest, dann müssten die Dateien ja im RAM gepuffert sein ... geht's dann deutlich schneller?
Never change a broken system. It could be worse afterwards.

"No computer system can be absolutely secure." Intel Document Number: 336983-001

geier22

Re: System durch Festplatte zu langsam?

Beitrag von geier22 » 21.02.2018 19:38:13

Ich glaube auch nicht, dass es an den Festplatten liegt
Meine Sysemplatte und die Datenplatten sind auch nicht mehr die jüngsten, älter als deine
ID-1: /dev/sdb model: WDC_WD5000HHTZ size: 500.1GB

Code: Alles auswählen

Power_On_Hours          0x0032   078   078   000    Old_age   Always       -       16533

Code: Alles auswählen

hdparm -tT /dev/sdb2/
dev/sdb2:
 Timing cached reads:   8300 MB in  2.00 seconds = 4153.55 MB/sec
 Timing buffered disk reads: 542 MB in  3.01 seconds = 180.22 MB/sec
ID-4: /dev/sdd model: SAMSUNG_HD753LJ size: 750.2GB

Code: Alles auswählen

Power_On_Hours          0x0032   094   094   000    Old_age   Always       -       32514

Code: Alles auswählen

/dev/sdd1:
 Timing cached reads:   8478 MB in  2.00 seconds = 4242.66 MB/sec
 Timing buffered disk reads: 260 MB in  3.01 seconds =  86.32 MB/sec
Auf der SAMSUNG_HD753LJ habe ich z.B. Meine VM's liegen, die alle recht flott starten.

Was beim Booten hängt, kannst du ja mal mit

Code: Alles auswählen

systemd-analyze critical-chain 
überpüfen
Anhaltspunkt: Mein System auf der WDC_WD5000HHTZ.
Das reicht aber gade mal, um sich einen Kaffee einzuschenken :mrgreen:

Code: Alles auswählen

systemd-analyze time 
Startup finished in 3.844s (kernel) + 11.208s (userspace) = 15.052s
graphical.target reached after 11.196s in userspace

buhtz
Beiträge: 1099
Registriert: 04.12.2015 17:54:49
Kontaktdaten:

Re: System durch Festplatte zu langsam?

Beitrag von buhtz » 22.02.2018 13:15:15

Die CPU langweilt sich (laut Graph und Balken in der XFCE-Leiste).

Code: Alles auswählen

$ sudo systemd-analyze time
Startup finished in 4.750s (kernel) + 51.561s (userspace) = 56.312s
graphical.target reached after 50.891s in userspace
Debian 11 & 12; Desktop-PC, Headless-NAS, Raspberry Pi 4
Teil des Upstream Betreuer Teams von Back In Time (Debianbackintime)

Benutzeravatar
Lord_Carlos
Beiträge: 5578
Registriert: 30.04.2006 17:58:52
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: Dänemark

Re: System durch Festplatte zu langsam?

Beitrag von Lord_Carlos » 22.02.2018 13:20:17

Eine Minute zum starten? Oh wow.

Du kannst gucken was so viel Zeit braucht mit:
systemd-analyze blame
Oder als Bild:
systemd-analyze plot > plot.svg

Code: Alles auswählen

╔═╗┬ ┬┌─┐┌┬┐┌─┐┌┬┐╔╦╗
╚═╗└┬┘└─┐ │ ├┤ │││ ║║
╚═╝ ┴ └─┘ ┴ └─┘┴ ┴═╩╝ rockt das Forum!

buhtz
Beiträge: 1099
Registriert: 04.12.2015 17:54:49
Kontaktdaten:

Re: System durch Festplatte zu langsam?

Beitrag von buhtz » 22.02.2018 22:08:46

Code: Alles auswählen

         17.149s systemd-journal-flush.service
         14.633s dev-sda1.device
         10.316s apt-daily.service
          9.974s NetworkManager-wait-online.service
          8.475s NetworkManager.service
          7.754s ModemManager.service
          6.704s udisks2.service
          6.331s wpa_supplicant.service
          6.067s virtualbox.service
          5.848s networking.service
          5.775s accounts-daemon.service
          5.257s systemd-udevd.service
          4.626s loadcpufreq.service
          4.302s upower.service
          4.004s preload.service
          3.669s lvm2-monitor.service
          3.562s gpm.service
          3.534s dns-clean.service
          3.505s systemd-tmpfiles-setup-dev.service
          3.342s pppd-dns.service
          2.833s systemd-modules-load.service
          2.476s plymouth-quit.service
          2.475s plymouth-quit-wait.service
          2.386s avahi-daemon.service
          2.346s polkit.service
          2.146s proc-sys-fs-binfmt_misc.mount
          2.118s qemu-guest-agent.service
          1.984s keyboard-setup.service
          1.466s lm-sensors.service
          1.438s ssh.service
          1.374s colord.service
          1.329s user@1000.service
          1.153s plymouth-read-write.service
          1.126s systemd-backlight@backlight:acpi_video0.service
          1.064s systemd-logind.service
           976ms run-rpc_pipefs.mount
           876ms nfs-config.service
           867ms rpcbind.service
           833ms console-setup.service
           825ms systemd-timesyncd.service
           760ms systemd-remount-fs.service
           698ms dev-mqueue.mount
           696ms sys-kernel-debug.mount
           686ms systemd-sysctl.service
           683ms dev-hugepages.mount
           497ms apt-daily-upgrade.service
           429ms systemd-udev-trigger.service
           377ms systemd-random-seed.service
           365ms dev-disk-by\x2duuid-a0fdc21c\x2de2e7\x2d4b92\x2d93bc\x2d5ebb5a2f32e6.swap
           342ms systemd-journald.service
           334ms blk-availability.service
           330ms systemd-user-sessions.service
           307ms systemd-tmpfiles-setup.service
           187ms plymouth-start.service
           160ms systemd-update-utmp.service
           123ms alsa-restore.service
            92ms glances.service
            92ms hddtemp.service
            86ms rc-local.service
            57ms openvpn.service
            56ms systemd-tmpfiles-clean.service
            47ms sddm.service
            31ms kmod-static-nodes.service
            24ms cpufrequtils.service
            13ms ifplugd.service
             5ms systemd-update-utmp-runlevel.service
             2ms sys-fs-fuse-connections.mount
813
Debian 11 & 12; Desktop-PC, Headless-NAS, Raspberry Pi 4
Teil des Upstream Betreuer Teams von Back In Time (Debianbackintime)

geier22

Re: System durch Festplatte zu langsam?

Beitrag von geier22 » 22.02.2018 22:46:20

Der von mir vorgeschlagene Befehl

Code: Alles auswählen

systemd-analyze critical-chain 
ist etwas übersichtlicher als der Plot, wo man kaum was lesen kann.
Erste 1. Hilfe:

Code: Alles auswählen

# journalctl --vacuum-time=5d
Das löscht erstmal alle Logs die älter als 5 Tage sind aus /var/log/journal/
Dann erst mal Neustart und schauen, ob sich was verbessert hat

In der /etc/systemd/journald.conf kannst du verschiedene Parameter einstellen:
Erklärung hier:
https://www.freedesktop.org/software/sy ... .conf.html
Parameter, die wichtig wären:
#SystemMaxUse=
#SystemKeepFree=
#SystemMaxFileSize=[
#MaxRetentionSec=
jeweils Werte (ein oder mehrere) setzen und auskommentieren

buhtz
Beiträge: 1099
Registriert: 04.12.2015 17:54:49
Kontaktdaten:

Re: System durch Festplatte zu langsam?

Beitrag von buhtz » 22.02.2018 22:59:55

Hab die logs gelöscht. Aber sollte systemd das nicht von alleine managen können oder von Seiten Debians eine sinnvolle Voreinstellung gewählt sein. Der Vacuum Befehl hat 1,5 GB gelöscht.

Code: Alles auswählen

         13.035s dev-sda1.device
         12.903s NetworkManager-wait-online.service
          8.945s preload.service
          8.056s loadcpufreq.service
          8.043s ModemManager.service
          6.767s udisks2.service
          6.252s NetworkManager.service
          5.319s avahi-daemon.service
          5.302s systemd-udevd.service
          5.180s accounts-daemon.service
          5.170s lm-sensors.service
          4.717s lvm2-monitor.service
          4.394s systemd-journal-flush.service
          4.320s networking.service
          4.212s upower.service
          3.668s colord.service
          3.635s gpm.service
          3.121s dns-clean.service
          3.092s wpa_supplicant.service
          2.860s systemd-tmpfiles-setup-dev.service
          2.524s systemd-modules-load.service
          2.067s rpcbind.service
          1.872s ssh.service
          1.769s polkit.service
          1.731s systemd-tmpfiles-setup.service
          1.369s proc-sys-fs-binfmt_misc.mount
          1.322s keyboard-setup.service
          1.318s run-rpc_pipefs.mount
          1.269s qemu-guest-agent.service
          1.107s plymouth-read-write.service
          1.018s user@1000.service
          1.017s sddm.service
           878ms virtualbox.service
           859ms dev-mqueue.mount
           839ms systemd-remount-fs.service
           803ms sys-kernel-debug.mount
           799ms systemd-update-utmp.service
           784ms dev-hugepages.mount
           672ms systemd-backlight@backlight:acpi_video0.service
           663ms alsa-restore.service
           576ms pppd-dns.service
           575ms systemd-sysctl.service
           536ms systemd-timesyncd.service
           525ms systemd-journald.service
           520ms systemd-logind.service
           466ms systemd-random-seed.service
           460ms blk-availability.service
           442ms systemd-udev-trigger.service
           371ms glances.service
           295ms dev-disk-by\x2duuid-a0fdc21c\x2de2e7\x2d4b92\x2d93bc\x2d5ebb5a2f32e6.swap
           279ms nfs-config.service
           224ms openvpn.service
           222ms systemd-user-sessions.service
           208ms console-setup.service
           187ms plymouth-start.service
           141ms kmod-static-nodes.service
            45ms plymouth-quit.service
            45ms plymouth-quit-wait.service
            38ms hddtemp.service
            27ms rc-local.service
            23ms cpufrequtils.service
            10ms ifplugd.service
             6ms systemd-update-utmp-runlevel.service
             2ms sys-fs-fuse-connections.mount
[code]

Sieht schon besser. Einige Sekunden schnelle beim Booten.
Die manpage zu der journal.conf ist wie üblich wenig hilfreich, wenn man kein Hintergrundwisen hat. Woher soll ich den wissen, was ich da für Dateigrößen nehmen soll? Zumal ich weiß, dass jsystemd seine logs binär speichert und nicht als text, kann ich noch weniger abschätzen, wieviele log gleich wieviel Bytes sind. ;)
Debian 11 & 12; Desktop-PC, Headless-NAS, Raspberry Pi 4
Teil des Upstream Betreuer Teams von Back In Time (Debianbackintime)

NAB
Beiträge: 5501
Registriert: 06.03.2011 16:02:23
Lizenz eigener Beiträge: MIT Lizenz

Re: System durch Festplatte zu langsam?

Beitrag von NAB » 23.02.2018 01:29:45

Urgs ... dass systemd sich bei jedem Start durch sämtliche alten Logdateien wühl, wusste ich auch noch nicht. Sieht auch nicht so ganz ausgegoren aus ...

buhtz, du solltest mal gucken, was da überhaupt so alles drinsteh in deinem Syslog:
journalctl -a
Wenn da alle paar Sekunden was reinquasselt, möchtest du vielleicht wissen was und warum.

Debian nimmt in der /etc/systemd/journald.conf gar keine Einstellungen vor sondern lässt alles auf Systemd-Default. Das bedeutet, systemd darf 15% deiner Festplatte, maximal 4 GB mit Logfiles belegen.

Hier gibt's nen Systemd-Crashkurs auf Deutsch:
https://mywiki.bluelupo.net/wiki/Grundl ... zu_systemd
Never change a broken system. It could be worse afterwards.

"No computer system can be absolutely secure." Intel Document Number: 336983-001

buhtz
Beiträge: 1099
Registriert: 04.12.2015 17:54:49
Kontaktdaten:

Re: System durch Festplatte zu langsam?

Beitrag von buhtz » 23.02.2018 09:04:10

Nochmal nachgefragt:
Diese systemd-Zeit-Ausgaben, deren Interpretation mir schwer fällt, sagen euch also, dass der Log-Mechanismus von SystemD hier ein gewichtiger Faktor ist?

Mich wundert das alles sehr, da ich daran IMO nix gedreht habe. Das ist alles default-Einstellung. Warum renne ich dann also in so ein Performance-Problem und ihr nicht?
Debian 11 & 12; Desktop-PC, Headless-NAS, Raspberry Pi 4
Teil des Upstream Betreuer Teams von Back In Time (Debianbackintime)

geier22

Re: System durch Festplatte zu langsam?

Beitrag von geier22 » 23.02.2018 12:45:34

Um auszuschließen, dass es irgendeine System- Fehleinstellung bei dir ist, hätte ich den Vorschlag, das System im Recovety- Modus zu starten.
Dort gibst du nochmal ein:

Code: Alles auswählen

systemd-analyze blame >/home/[dein Benutzername]/blame.txt
und

Code: Alles auswählen

systemd-analyze time >/home/[dein Benutzername]/time.tx
buhtz hat geschrieben: ↑ zum Beitrag ↑
22.02.2018 22:59:55
13.035s dev-sda1.device
sieht bei mir dann so aus (allerdings SSD):

blame:

Code: Alles auswählen

     
           347ms dev-sdc1.device                                          ------> Systemplatte (SSD)
           226ms systemd-timesyncd.service
           225ms apparmor.service
           193ms systemd-journal-flush.service
           121ms systemd-modules-load.service
           108ms systemd-journald.service
           101ms keyboard-setup.service
           100ms systemd-update-utmp.service
            87ms systemd-fsck@dev-disk-by\x2duuid-7a7e7ac0\x2df89f\x2d4e91\x2dbea1\x2ddc1b5da85293.service
            85ms systemd-udev-trigger.service
            83ms media-HD753LJ.mount                                       -----> Das ist eine Festplatte (mein Methusalem)
            65ms console-setup.service
            52ms systemd-tmpfiles-setup-dev.service
            49ms systemd-udevd.service
            44ms media-cinnamonhome.mount                                ---> das ist einen Festplatte
            40ms dev-disk-by\x2duuid-aa201965\x2d5dcb\x2d4abb\x2d8283\x2dc9bcd378aa1e.swap
            34ms plymouth-start.service
            17ms systemd-tmpfiles-setup.service
            17ms plymouth-read-write.service
            11ms systemd-sysctl.service
            10ms systemd-remount-fs.service
             9ms dev-hugepages.mount
             9ms home.mount
             8ms sys-kernel-debug.mount
             8ms kmod-static-nodes.service
             5ms dev-mqueue.mount
             5ms systemd-update-utmp-runlevel.service
             5ms systemd-random-seed.service
             2ms tmp.mount
und time:

Code: Alles auswählen

Startup finished in 2.846s (kernel) + 909ms (userspace) = 3.755s
graphical.target was never reached
der Zugriff auf dev-sda (ich vermute mal, dass das die Platte ist auf der dein System ist) ist exorbitant hoch, der liegt bei mir im Millisekunden Bereich (347ms dev-sdc1.device)
Erklären kann ich mir das nicht so richtig, zumal die hdparm - Werte ja nun keine riesigen Ausreißer darstellen.

Und dann poste doch mal gleich nach dem Start - wie schon vorgeschlagen - die Ausgabe von

Code: Alles auswählen

# dmesg -T
Aber nach NoPaste :!: :!: :!:

NAB
Beiträge: 5501
Registriert: 06.03.2011 16:02:23
Lizenz eigener Beiträge: MIT Lizenz

Re: System durch Festplatte zu langsam?

Beitrag von NAB » 23.02.2018 15:56:24

buhtz hat geschrieben: ↑ zum Beitrag ↑
23.02.2018 09:04:10
Diese systemd-Zeit-Ausgaben, deren Interpretation mir schwer fällt, sagen euch also, dass der Log-Mechanismus von SystemD hier ein gewichtiger Faktor ist?
Nein, das tun sie nicht. Einen "gewichtigen" Faktor haben wir bisher nicht gefunden.
Bevor du deine Logs aufgeräumt hast, hat "systemd-journal-flush.service" als langsamster Faktor deinen Start um 17 Sekunden verzögert. Nach dem Aufräumen sind es noch 4 Sekunden. Das macht magere 13 Sekunden Gewinn ... dann ist der Kaffee immer noch fast fertig.

Das Langsamste beim Starten ist jetzt deine Festplatte "dev-sda1.device" mit 13 Sekunden. Das ist zwar auch etwas viel, aber deine WD Green ist ja auch kein Rennpferd.

Und die ganzen "systemd-Zeit-Ausgaben" betreffen auch nur das "Booten", also die 1:10, die du hier:
viewtopic.php?f=13&t=168763#p1165707
bestimmt hast. Was er die 1:55 lang macht, bis XFCE fertig ist, wissen wir immer noch nicht.

Fragen nach der CPU-Auslastung, danach ob Firefox beim zweiten Versuch schneller startet und ob du im Journal auffällig dauernd wiederholte Meldungen findest, beantwortest du nicht.
buhtz hat geschrieben: ↑ zum Beitrag ↑
23.02.2018 09:04:10
Mich wundert das alles sehr, da ich daran IMO nix gedreht habe. Das ist alles default-Einstellung. Warum renne ich dann also in so ein Performance-Problem und ihr nicht?
1) Sind die Systemd-Logs nur ein kleiner Teil deines Performance-Problems.
2) Verstehe ich die Sache auch nicht so richtig. Ich lese hier immer wieder, dass Systemd bei einer Neuinstallation gar keine Logs auf der Platte mehr anlegen sollte. Tut's bei mir aber, vielleicht weil ich immer "manuelle Installation" mit ein paar Extras auswähle. Ist aber eigentlich auch egal - wichtig ist, dass du es so einstellst, wie es für dich passt. Eine Universalinstallation, die bei jedem perfekt läuft, gibt es nicht. Debian kann immer nur "so ungefähr" das Richtige vorgeben.
Never change a broken system. It could be worse afterwards.

"No computer system can be absolutely secure." Intel Document Number: 336983-001

Benutzeravatar
MSfree
Beiträge: 10686
Registriert: 25.09.2007 19:59:30

Re: System durch Festplatte zu langsam?

Beitrag von MSfree » 23.02.2018 16:04:07

Hier: viewtopic.php?f=12&t=164362&p=1165991#p1165991
und hier: viewtopic.php?f=33&t=164929&hilit=H%C3% ... im+mounten

waren es jeweils die Swap-Partitionen, die nach einem Umbau gar nicht mehr vorhanden oder eine neue UUID bekommen hatten. Letztlich muß in dem Fall eine neue initrd angelegt werden.

buhtz
Beiträge: 1099
Registriert: 04.12.2015 17:54:49
Kontaktdaten:

Re: System durch Festplatte zu langsam?

Beitrag von buhtz » 23.02.2018 23:43:23

Firefox braucht beim ersten Start 22 und beim zweiten nur 4 Sekunden.

Vielleicht relevant meine Bootparameter:

Code: Alles auswählen

BOOT_IMAGE=/boot/vmlinuz-4.15.3-towo.1-siduction-amd64 root=UUID=6419425e-7001-4b2c-9c4b-9ef782249916 ro systemd.show_status=1 resume=/dev/sda5
Swap ist meines Wissens (von mir früher mal) deaktivert worden.

Code: Alles auswählen

$ sudo sfdisk -l
[sudo] Passwort für user: 
Disk /dev/sda: 1,8 TiB, 2000398934016 bytes, 3907029168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00095aa3

Device     Boot      Start        End    Sectors  Size Id Type
/dev/sda1             2048 3890251775 3890249728  1,8T 83 Linux
/dev/sda2       3890251776 3907028991   16777216    8G  5 Extended
/dev/sda5       3890253824 3907028991   16775168    8G 82 Linux swap / Solaris

$ sudo cat /proc/swaps
Filename				Type		Size	Used	Priority
/dev/sda5                               partition	8387580	0	-2

$ free
              total        used        free      shared  buff/cache   available
Mem:        7995524      796404     6147344      171312     1051776     6863616
Swap:       8387580           0     8387580
Daten aus dem recovery mode

Code: Alles auswählen

         13.377s dev-sda1.device
          6.009s systemd-journal-flush.service
          3.289s systemd-udevd.service
          3.253s systemd-tmpfiles-setup.service
          2.693s lvm2-monitor.service
          2.463s systemd-tmpfiles-setup-dev.service
          2.445s systemd-timesyncd.service
          1.823s systemd-modules-load.service
          1.066s keyboard-setup.service
           974ms systemd-journald.service
           844ms systemd-backlight@backlight:acpi_video0.service
           681ms sys-kernel-debug.mount
           677ms systemd-remount-fs.service
           622ms systemd-random-seed.service
           619ms dev-mqueue.mount
           614ms dev-hugepages.mount
           315ms systemd-udev-trigger.service
           229ms systemd-update-utmp.service
           186ms plymouth-start.service
           175ms plymouth-read-write.service
           171ms blk-availability.service
            97ms systemd-sysctl.service
            88ms kmod-static-nodes.service
            87ms dev-disk-by\x2duuid-a0fdc21c\x2de2e7\x2d4b92\x2d93bc\x2d5ebb5a2f32e6.swap
             5ms systemd-update-utmp-runlevel.service

Code: Alles auswählen

Startup finished in 4.553s (kernel) + 17.249s (userspace) = 21.802s
graphical.target was never reached
Dmesg Output: pastebin/?mode=view&s=40166
Zuletzt geändert von buhtz am 24.02.2018 13:46:35, insgesamt 2-mal geändert.
Debian 11 & 12; Desktop-PC, Headless-NAS, Raspberry Pi 4
Teil des Upstream Betreuer Teams von Back In Time (Debianbackintime)

NAB
Beiträge: 5501
Registriert: 06.03.2011 16:02:23
Lizenz eigener Beiträge: MIT Lizenz

Re: System durch Festplatte zu langsam?

Beitrag von NAB » 24.02.2018 00:12:40

buhtz hat geschrieben: ↑ zum Beitrag ↑
23.02.2018 23:43:23
Firefox braucht beim ersten Start 22 und beim zweiten nur 4 Sekunden.
Dieser beachtliche Unterschied deutet deutlich auf "Festplatte" hin. Entweder ist sie wirklich so langsam, oder irgendwas anderes greift noch massiv auf die Festplatte zu und bremst sie dabei massiv aus, weil die Leseköpfe dauernd umherspringen müssen ... das müsstest du aber eigentlich leise hektisch Klackern hören. So oder so würd ne kleine 128 GB SSD da ordentlich Schwung reinbringen.

Die ganzen Boot-Geschichten haben garantiert nichts damit zu tun, dass er _nach_ dem Booten geschlagene 24 Sekunden braucht, um Firefox zu öffnen.

Benutzt du irgendein ungewöhnliches Dateisystem, das unter Kernel 4.15 einen "extra langsam"-Bug haben könnte?

Deine Swap-Partition dürfte Systemd automatisch in Betrieb nehmen. Solange du kein Suspend-to-disk machst, müsste er beim Booten einfach feststellen, dass darauf kein Resume-Image zu finden ist und es sich egal sein lassen.
Never change a broken system. It could be worse afterwards.

"No computer system can be absolutely secure." Intel Document Number: 336983-001

buhtz
Beiträge: 1099
Registriert: 04.12.2015 17:54:49
Kontaktdaten:

Re: System durch Festplatte zu langsam?

Beitrag von buhtz » 24.02.2018 00:15:50

...
Zuletzt geändert von buhtz am 24.02.2018 13:46:48, insgesamt 1-mal geändert.
Debian 11 & 12; Desktop-PC, Headless-NAS, Raspberry Pi 4
Teil des Upstream Betreuer Teams von Back In Time (Debianbackintime)

Antworten