[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.
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)

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:16:08

...
Zuletzt geändert von buhtz am 24.02.2018 13:46:56, 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)

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:52:44

Vermutlich wird dir gleich ein Moderator erklären, dass du solche langen Texte bei Nopaste:
pastebin/
hochladen sollst und hier dann nur den Link, den du dort bekommst, reinschreiben sollst :wink:

Der gesamte abgebildete Bootprozess dauert nur 21 Sekunden, von 00:05:22 bis 00:05:43. Das sieht ziemlich normal aus.

Mit einer Ausnahme: dir schmiert drei mal i915/intel_audio.c ab, jeweils ab dem
" ------------[ cut here ]------------"
bis zum
"---[ end trace "
Danach scheint aber alles normal weiterzulaufen, und da du danach noch 2 Minuten warten musst, bis du eingeloggt bist, hört er ab 00:05:41 wohl auch auf mit Abstürzen.
Never change a broken system. It could be worse afterwards.

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

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 » 24.02.2018 08:58:23

Neue SSD gibt es ab 40 - 50 EUR.
Komisch finde ich das ich die gebraucht auch nicht billiger sehe *gruebel*

Hat vielleicht jemand in deinem Bekanntenkreis eine abzugeben?
So bin ich an zwei 128GB gekommen.

Code: Alles auswählen

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

geier22

Re: System durch Festplatte zu langsam?

Beitrag von geier22 » 24.02.2018 10:26:55

Ich kann mich des Eindrucks nicht erwehren, dass deine Festplatte - aus bisher nicht ersichtlichen Grund - nicht mehr will.
Im recovery mode werden lediglich wenige Units gestartet. Der Zugriff (oder was auch immer das ist) auf dev-sda ist ähnlich lang und addiert sich bei normalem Start (allein bei den Werten > 1min) auf "schlanke" 2,9 Minuten !!
Ich habe mal Siduction Xfce in einer VM installiert: Der Start (bis zur Bedienbarkeit) dauert 28 Sekunden :!:

Code: Alles auswählen

$ systemd-analyze time
Startup finished in 5.588s (kernel) + 10.417s (userspace) = 16.006s
graphical.target reached after 10.375s in userspace
buhtz hat geschrieben: ↑ zum Beitrag ↑
23.02.2018 23:43:23
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
buhtz hat geschrieben: ↑ zum Beitrag ↑
22.02.2018 22:08:46
Daten aus normalen Start

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[/quote]

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

Re: System durch Festplatte zu langsam?

Beitrag von buhtz » 24.02.2018 13:52:27

geier22 hat geschrieben: ↑ zum Beitrag ↑
24.02.2018 10:26:55
Ich habe mal Siduction Xfce in einer VM installiert: Der Start (bis zur Bedienbarkeit) dauert 28 Sekunden :!:

Code: Alles auswählen

$ systemd-analyze time
Startup finished in 5.588s (kernel) + 10.417s (userspace) = 16.006s
graphical.target reached after 10.375s in userspace
Wow, vielen herzlichen Dank für den Aufwand! :THX:

Nun mache ich mir Gedanken über neue Hardware. Sollte ich dazu vielleicht doch einen neuen Thread öffnen?
Ich besitze hier ein Slim Gehäuse. Da ist ein Steckplatz für ein mSATA SSD Modul. Dazu kann man noch ein 3,5" Gerät (z. B. eine HDD) oder zwei 2,5" Geräte einbauen.

Option 1 ( ~100 € ):
Die ursprüngliche Idee war, zu der aktuellen 3,5" HDD ein mSATA SSD einzubauen. Kosten ~100 € für 256 GB. Da kommt Debian drauf und /home landet, bis auf kleine Ausnahmen die ich per bind-mount regle, weiter auf der HDD.

Option 2 ( ~300 € ):
Nur eine neue 1 TB SSD einbauen. Da sind wir schnell um die ~300,- € (Samsung Evo).

Option 3 ( ~230 € ):
Eine 2,5" SDD mit 250-500 GB für ca. 90 bis 130 € und eine weitere 2,5" HDD für ca. 100,- € noch dazu.

Alle drei Optionen werden Geschwindigkeitsvorteile bringen. Der preisliche Unterschied zwischen den Optionen ist für mich durchaus relevant, aber auch die teuerste Option 2 wäre machbar. Entscheidend für die Auswahl ist eigentlich die Glaskugel-Frage, ob meine aktuelle 3,5" HDD demnächst abraucht. Wenn man die noch als zuverlässig einstufen könnte, würde ich die günstigste Option 1 wählen.

Wenn nicht, stellt sich bei der Wahl zwischen Option 2 & 3 die Frage, was technisch sinnvoller ist. Da gibt es ja einige Mythen bzw. auch veraltete Ansichten bezüglich SSDs. Sollte man heute ein System zu 100% auf eine SSD legen oder ist ein Mischbetrieb (z. B. viele kleine häufig geschriebene Dateien gehören auf die HDD) sinnvoller? Hab dazu nochmal den Thread "SSD: Mython und Realität" aufgemacht.
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 » 24.02.2018 15:02:28

Warum /home auf die HDD?
Viele kleine config und z.B. browser cache liegt in ~/

Ich wuerde /home auf die SSD legen, und dann grosse Daten, also Filme und Bilder auf die HDD.

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 » 24.02.2018 15:46:06

Lord_Carlos hat geschrieben: ↑ zum Beitrag ↑
24.02.2018 15:02:28
Warum /home auf die HDD?
Viele kleine config und z.B. browser cache liegt in ~/

Ich wuerde /home auf die SSD legen, und dann grosse Daten, also Filme und Bilder auf die HDD.
Das wäre inhaltlich auch mein Plan. Diese config und caches in Home wären die Ausnahme, die ich per bind-mount auf die SSD legen würde.
Die "grossen Daten" sind aber auch auf /home. ;)
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 16:41:13

Also ich sehe keine Hinweise, dass die HDD "nicht mehr will". Aber ich vermute, Grund für die ungewöhnliche Langsamkeit sind viele HDD-Zugriffe. Ich hab nur keine Ahnung, was das sein könnte. Ich hab schon geguckt, ob XFCE inzwischen einen Datei-Indexer haben könnte, so wie KDE, aber ich find da nix.

buhtz, schau dir noch mal die Ausgabe von
journalctl -b
an. Es geht weniger darum, was da drin steht, sondern ob da was jede Sekunde reinschreibt. Und schau noch mal unter /var/log/ nach, ob da eine Datei auffällig alle paar Sekunden wächst.

Ebenfalls interessant ist ~/.xsession-errors
Wie groß ist die? Wächst die dauernd?
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 » 24.02.2018 17:58:47

NAB hat geschrieben: ↑ zum Beitrag ↑
24.02.2018 16:41:13
Also ich sehe keine Hinweise, dass die HDD "nicht mehr will". Aber ich vermute, Grund für die ungewöhnliche Langsamkeit sind viele HDD-Zugriffe. Ich hab nur keine Ahnung, was das sein könnte. Ich hab schon geguckt, ob XFCE inzwischen einen Datei-Indexer haben könnte, so wie KDE, aber ich find da nix.
Aber im recovery mode ist sie doch auch nicht wesentlich schneller. Da ist Xfce noch gar nicht gestartet. Das ist ja das seltsame

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

Re: System durch Festplatte zu langsam?

Beitrag von buhtz » 25.02.2018 09:27:19

NAB hat geschrieben: ↑ zum Beitrag ↑
24.02.2018 16:41:13
journalctl -b
Da werde ich immer noch nicht warm mit. :D Wie bekomme ich journalctl dazu mir automatisch neue Einträge anzuzeigen - so wie früher mit tail -f log.file ?
NAB hat geschrieben: ↑ zum Beitrag ↑
24.02.2018 16:41:13
Ebenfalls interessant ist ~/.xsession-errors
Wie groß ist die? Wächst die dauernd?
Die ist mal eben 82MB groß. ;) Da stehen aber keine Zeitstempel drin - was ein log file IMO wertlos macht.
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 » 25.02.2018 09:40:08

buhtz hat geschrieben: ↑ zum Beitrag ↑
25.02.2018 09:27:19
Wie bekomme ich journalctl dazu mir automatisch neue Einträge anzuzeigen - so wie früher mit tail -f log.file?
journalctl --help hat geschrieben:

Code: Alles auswählen

journalctl [OPTIONS...] [MATCHES...]

Query the journal.

Options:
[…]
  -f --follow                Follow the journal
[…]
… geht immer noch wie früher™, mit ›Befehl --help‹ und auch ›man Befehl‹.

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

Re: System durch Festplatte zu langsam?

Beitrag von buhtz » 25.02.2018 09:46:02

niemand hat geschrieben: ↑ zum Beitrag ↑
25.02.2018 09:40:08
… geht immer noch wie früher™, mit ›Befehl --help‹ und auch ›man Befehl‹.
Unter follow konnte ich mir aber nix vorstellen. Es fehlt mir einfach häufig auch der korrekte Suchbegriff im Kopf. ;)

Hatte gerade spontan die IDee ein zweites Desktop-Environment zu installieren und den Start mal zu messen. Hatte Xfce schon immer im Verdacht. X hat aber gerade diverse Bugs offen, so dass ich das in Debian unstable nicht tun kann.
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 » 25.02.2018 09:48:14

Naja … heißt in der --help-Ausgabe von tail genauso.

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

Re: System durch Festplatte zu langsam?

Beitrag von buhtz » 25.02.2018 10:01:56

NAB hat geschrieben: ↑ zum Beitrag ↑
24.02.2018 16:41:13
journalctl -b
an. Es geht weniger darum, was da drin steht, sondern ob da was jede Sekunde reinschreibt. Und schau noch mal unter /var/log/ nach, ob da eine Datei auffällig alle paar Sekunden wächst.
Wärend dem booten ist das schwer zu überwachen.

Konnte mich mit einer zweiten Maschine ab X-start per SSH einloggen und das journal-log verfolgen. Bin da kein Fachmann, aber es sieht nicht auffällig aus. Keine besonders häufiges Schreiben oder so.
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 » 25.02.2018 10:43:00

Hmm - ich bin der Meinung, wenn das Problem mit deiner dev-sda1 nicht gelöst wird, brauchst du auch nach anderem nicht zu sehen.
Und das lässt sich am übersichtlichsten im recovery modus machen.
wenn du da als root eingeloggt bist,

Code: Alles auswählen

journalctl -b  > irgendeinen Datei in deinem Home.txt
Du kannst die ganze Datei auch hier einstellen aber bitte nach NoPaste :!: :!:
Daten aus dem recovery mode, die du ja schon eingestellt hattest:

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
Das Journal kannst du dir dann ganz in Ruhe anschauen und nach Zeitsprüngen, Fehlermeldungen und Warnungen suchen.
buhtz hat geschrieben: ↑ zum Beitrag ↑
25.02.2018 09:27:19
Die ist mal eben 82MB groß. ;)
Das weißt darauf hin, dass du dich bisher nicht allzu viel um dein System gekümmert hast, oder ein wild gewordenes Programm die Datei voll-schreibt.
Abhilfe: löschen, auch die xsession-errors.old ---> wird beim Neustart wieder angelegt und ist dann aussagefähiger.
oder im "live" Modus: :mrgreen:

Code: Alles auswählen

$ >~/.xsession-errors

Antworten