Buster teilweise etwas langsam

Du kommst mit der Installation nicht voran oder willst noch was nachfragen? Schau auch in den "Tipps und Tricks"-Bereich.
Antworten
halo44
Beiträge: 703
Registriert: 12.05.2015 15:19:13

Buster teilweise etwas langsam

Beitrag von halo44 » 20.05.2019 12:17:54

Entschuldigt bitte, daß mir mir kein besseres Thema für mein Problem einfällt.

Im Gegensatz zur Buster-Installation auf meinem Notebook läuft Buster auf meinem Desktoprechner nicht ganz "rund".

Am deutlichsten zeigt sich das, wenn ich im Dateimanager Dolphin einen Ordner mit vielen Dateien im Ansichtsmodus "Details" öffne. Dann werden die Zeilen der Dateieinträge langsam von oben nach unten aufgebaut. Je nach Anzahl der Dateien bleibt dieser Vorgang sogar für Sekunden "hängen", bis weiter aufgebaut wird. In diesem Fall sind die Dateinamen, das Änderungsdatum, der Eigentümer und die Benutzergruppe bereits sichtbar. Lediglich die Größenangabe wird verzögert aufgebaut.

Verzögerungen treten auch beim Chrome-Browser auf, wenn ich bei mehreren Tabs von einem zum anderen wechsele oder einen der Tabs schliesse.

Gelegentlich werden die eingetippten Buchstaben bei Office-Dokumenten verzögert abgebildet.

In der in eigenen Partitionen auf dem Rechner befindlichen Stretch-Installation treten alle diese Verzögerungen nicht auf. Wie eingangs schon erwähnt habe ich diese Probleme auf der Notebook-Installation von Buster nicht.

Ich habe auch in weiteren Partitionen auf dem Desktoprechner ein weiteres Buster ohne zusätzliche Anwendungen und Anpassungen installiert. Auch in dieser schlanken Installation zeigt Dolphin die erwähnten Verzögerungen.

Beide Rechner laufen mit SSDs. Im Desktoprechner ist auch noch eine HDD verbaut. Auf dieser befinden sich neben Partitionen, die nur bei Bedarf gemountet werden, auch die Swap-Partition, die wie der Hauptspeicher 8 GB hat. Diese wird nur dann benutzt, wenn ich den Rechner in Tiefschlaf versetze, was ich oft nutze.

Zum Rechner sagt inxi

Code: Alles auswählen

CPU: Quad Core AMD A8-6600K APU with Radeon HD Graphics (-MCP-) speed/min/max: 1896/1900/3900 MHz 
Kernel: 4.19.0-5-amd64 x86_64 Up: 2h 59m Mem: 2004.2/7247.9 MiB (27.7%) Storage: 696.80 GiB (19.8% used) 
Procs: 214 Shell: bash 5.0.3 inxi: 3.0.32
Hat vielleicht jemand eine Idee, welches Problem mein Rechner mit Buster haben kann? Ich bin für jeden Hinweis und Hilfe sehr dankbar.

Gruss H.

Benutzeravatar
Blackbox
Beiträge: 4289
Registriert: 17.09.2008 17:01:20
Lizenz eigener Beiträge: GNU Free Documentation License

Re: Buster teilweise etwas langsam

Beitrag von Blackbox » 23.05.2019 12:10:32

Keine Idee, aber hast du das Paket: Debianamd64-microcode installiert?
Eventuell hilft es auch bei deinen Performanceproblemen, aber zumindest bringt es etwas mehr Sicherheit für dich bzw. deine CPU.
Eigenbau PC: Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Desktop PC: Dell Inspiron 530 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Notebook: TUXEDO BU1406 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Alles Minimalinstallationen und ohne sudo/PA/PW.
Rootserver: Rocky Linux 9.3 - Kernel: 5.14

Freie Software unterstützen, Grundrechte stärken!

halo44
Beiträge: 703
Registriert: 12.05.2015 15:19:13

Re: Buster teilweise etwas langsam

Beitrag von halo44 » 23.05.2019 15:22:54

Blackbox hat geschrieben: ↑ zum Beitrag ↑
23.05.2019 12:10:32
Keine Idee, aber hast du das Paket: Debianamd64-microcode installiert?
Eventuell hilft es auch bei deinen Performanceproblemen, aber zumindest bringt es etwas mehr Sicherheit für dich bzw. deine CPU.
Das Paket ist weder in meiner Stretch-Installation, die ohne Verzögerungen läuft, noch in der Buster-Installation installiert.

Ich habe es jetzt mal unter Buster installiert und den Rechner neu gestartet. Leider keine Verbesserung.

Ich lasse das Paket zunächst mal installiert, da es vermutlich keinen Schaden anrichtet.

Als nächstes versuche ich mal die HDD
/dev/sdb vendor: Western Digital model: WD5000BPVT-22HXZT1 size: 465.76 GiB
nicht weiter zu nutzen. Vielleicht macht diese ja Probleme.

Dazu muß ich allerdings meine Swap-Partition auf die SSD verlegen. Ich benötige diese Partition für den Suspend-to-Disk. Bisher habe ich vermieden hiermit die SSD zu beauftragen. Ganz wohl ist mir nicht dabei (Verschleiss?).

Gruss H.

Benutzeravatar
Blackbox
Beiträge: 4289
Registriert: 17.09.2008 17:01:20
Lizenz eigener Beiträge: GNU Free Documentation License

Re: Buster teilweise etwas langsam

Beitrag von Blackbox » 23.05.2019 15:37:03

Gibt es keine Hinweise in deinen Logs, insbesondere im Kernellog?
Eigenbau PC: Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Desktop PC: Dell Inspiron 530 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Notebook: TUXEDO BU1406 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Alles Minimalinstallationen und ohne sudo/PA/PW.
Rootserver: Rocky Linux 9.3 - Kernel: 5.14

Freie Software unterstützen, Grundrechte stärken!

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

Re: Buster teilweise etwas langsam

Beitrag von MSfree » 23.05.2019 15:55:35

halo44 hat geschrieben: ↑ zum Beitrag ↑
23.05.2019 15:22:54
Dazu muß ich allerdings meine Swap-Partition auf die SSD verlegen. Ich benötige diese Partition für den Suspend-to-Disk.
Eigentlich booten Rechner mit SSD schneller als sie vom Syspend-to-Disk aufwachen. Wenn es bei dir also keine ungewöhnliche Nutzung gibt, würde ich auf Suspend komplett verzichten und mit 8GB RAM braucht man normalerweise auf kein Swap.

Du kannst aber die Swapnutzung über den Parameter swappiness steuern und die Kiste so konfigurieren, daß praktisch nie geswapt wird, solange das RAM nicht wirklich voll ist, und die Swappartition nur noch für Suspend genutzt wird. Das hält die Schreibzyklen auf einem unschädlich niedrigen Niveau.

Aber selbst das ist eigentlich für Aluhüte. Die c't hat mal SSDs bis zum Kaputtschreiben getestet. Bei normaler Nutzung (also kein Serverbetrieb bei AWS oder Google) hält eine SSD rechnerisch deutlich über 20 Jahre.

halo44
Beiträge: 703
Registriert: 12.05.2015 15:19:13

Re: Buster teilweise etwas langsam

Beitrag von halo44 » 23.05.2019 19:28:28

Blackbox hat geschrieben: ↑ zum Beitrag ↑
23.05.2019 15:37:03
Gibt es keine Hinweise in deinen Logs, insbesondere im Kernellog?
Im Kernellog von Buster fällt mir auf
May 23 15:03:04 dt-debian kernel: [ 0.281833] AppArmor: AppArmor initialized

May 23 15:03:04 dt-debian kernel: [ 0.336025] AppArmor: AppArmor Filesystem Enabled

May 23 15:03:04 dt-debian kernel: [ 1.170260] AppArmor: AppArmor sha1 policy hashing enabled

May 23 15:03:04 dt-debian kernel: [ 4.436181] audit: type=1400 audit(1558616584.759:2): apparmor="STATUS" operation="profile_load" profile="unconfined" name="libreoffice-oopslash" pid=475 comm="apparmor_parser"
May 23 15:03:04 dt-debian kernel: [ 4.437179] audit: type=1400 audit(1558616584.759:3): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/sbin/libvirtd" pid=477 comm="apparmor_parser"
May 23 15:03:04 dt-debian kernel: [ 4.437231] audit: type=1400 audit(1558616584.759:4): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/sbin/libvirtd//qemu_bridge_helper" pid=477 comm="apparmor_parser"
May 23 15:03:04 dt-debian kernel: [ 4.437492] audit: type=1400 audit(1558616584.759:5): apparmor="STATUS" operation="profile_load" profile="unconfined" name="virt-aa-helper" pid=474 comm="apparmor_parser"
May 23 15:03:04 dt-debian kernel: [ 4.439378] audit: type=1400 audit(1558616584.763:6): apparmor="STATUS" operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=478 comm="apparmor_parser"
May 23 15:03:04 dt-debian kernel: [ 4.439428] audit: type=1400 audit(1558616584.763:7): apparmor="STATUS" operation="profile_load" profile="unconfined" name="nvidia_modprobe//kmod" pid=478 comm="apparmor_parser"
May 23 15:03:04 dt-debian kernel: [ 4.440602] audit: type=1400 audit(1558616584.763:8): apparmor="STATUS" operation="profile_load" profile="unconfined" name="libreoffice-xpdfimport" pid=480 comm="apparmor_parser"
May 23 15:03:04 dt-debian kernel: [ 4.440686] audit: type=1400 audit(1558616584.763:9): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/lib/x86_64-linux-gnu/lightdm/lightdm-guest-session" pid=476 comm="apparmor_parser"
May 23 15:03:04 dt-debian kernel: [ 4.440748] audit: type=1400 audit(1558616584.763:10): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/lib/x86_64-linux-gnu/lightdm/lightdm-guest-session//chromium" pid=476 comm="apparmor_parser"
während sich im Kernellog von Stretch nur das findet
May 23 14:28:51 dt-debian kernel: [ 0.004207] AppArmor: AppArmor disabled by boot time parameter
Ich kenne das System nicht. Wenn ich mal kurz recherchiere, kann ich mir schon vorstellen, daß es sich CPU-Zeit nimmt?

Gruss H.

halo44
Beiträge: 703
Registriert: 12.05.2015 15:19:13

Re: Buster teilweise etwas langsam

Beitrag von halo44 » 23.05.2019 19:35:53

@MSfree

danke Dir für Deine aufmunternden Worte. Klar bootet der Rechner tatsächlich schneller von SSD als er von HDD wieder aufgeweckt wird. Allerdings habe ich immer einige Programme, Dokumente und Tabellen auf. Die sind nach dem Aufwachen sofort im Aktuellen Bearbeitungsstatus da.

Ich werde vielleicht tatsächlich die Swappartition auf die SSD legen und auch die HDD ausmustern und durch SSD ersetzen.

Gruss H.

KP97
Beiträge: 3403
Registriert: 01.02.2013 15:07:36

Re: Buster teilweise etwas langsam

Beitrag von KP97 » 23.05.2019 19:48:15

Ich würde apparmor mal entfernen und dann sehen, ob das System dann schneller ist.
In meinem Sid läuft das nicht, nur die libapparmor1 ist vorhanden.

halo44
Beiträge: 703
Registriert: 12.05.2015 15:19:13

Re: Buster teilweise etwas langsam

Beitrag von halo44 » 23.05.2019 20:00:14

@KP97

Danke, werde ich morgen mal anfassen.

Gruss H.

halo44
Beiträge: 703
Registriert: 12.05.2015 15:19:13

Re: Buster teilweise etwas langsam

Beitrag von halo44 » 24.05.2019 09:29:56

Habe jetzt apparmor deinstalliert, die libapparmor1 aber belassen und den Rechner neu gestartet. Leider hat sich nichts verändert.

Mehrwürdig sind jedoch diese Einträge im kernellog:
May 24 09:07:04 dt-debian kernel: [ 0.282251] AppArmor: AppArmor initialized

May 24 09:07:04 dt-debian kernel: [ 0.340681] AppArmor: AppArmor Filesystem Enabled

May 24 09:07:04 dt-debian kernel: [ 1.174225] AppArmor: AppArmor sha1 policy hashing enabled
Darüber hinaus findet sich im Journal zusätzlich noch dieser Eintrag:
Mai 24 09:07:04 dt-debian systemd[1]: systemd 241 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid)
Was heißt das jetzt? Ein Dienst apparmor ist dem System nicht bekannt und läßt sich so auch nicht stoppen oder deaktivieren.

Wer kann helfen?

Gruss H.

halo44
Beiträge: 703
Registriert: 12.05.2015 15:19:13

Re: Buster teilweise etwas langsam

Beitrag von halo44 » 24.05.2019 11:04:37

Kann es sein, daß mein Problem mit dem bei Buster vorhandenen Kernel 4.19.0-5 zusammenhängt?

In der config-4.9.0-9-amd64 von Stretch finde ich
CONFIG_SECURITY_APPARMOR=y
CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE=1
CONFIG_SECURITY_APPARMOR_HASH=y
CONFIG_SECURITY_APPARMOR_HASH_DEFAULT=y
# CONFIG_DEFAULT_SECURITY_APPARMOR is not set
während die config-4.19.0-5-amd64 in Buster so aussieht
CONFIG_SECURITY_APPARMOR=y
CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE=1
CONFIG_SECURITY_APPARMOR_HASH=y
CONFIG_SECURITY_APPARMOR_HASH_DEFAULT=y
# CONFIG_SECURITY_APPARMOR_DEBUG is not set
CONFIG_DEFAULT_SECURITY_APPARMOR=y
CONFIG_DEFAULT_SECURITY="apparmor"
Hier sind die beiden letzten Einträge hinzugekommen bzw. sogar entgegengesetzte defaults setzen. Vielleicht liegt hier der Hund begraben, obwohl ja das Paket apparmor deinstalliert ist.

Gruss H.

KP97
Beiträge: 3403
Registriert: 01.02.2013 15:07:36

Re: Buster teilweise etwas langsam

Beitrag von KP97 » 24.05.2019 15:35:08

Ich habe in meinem selbstcompilierten 5.1.4 gar kein apparmor:
# CONFIG_SECURITY_APPARMOR is not set
aber das hilft Dir erstmal nichts.
Es gibt auch noch das Paket libpam-apparmor, das solltest Du auch deinstallieren, falls installiert.

Seltsam aber, daß auf Deinem Notebook dieser Fehler nicht auftritt. Hast Du da mal die Parameter und Einstellungen verglichen?
Testweise könntest Du auch mal den Kernel 5.0 aus experimental installieren:
https://packages.debian.org/experimenta ... runk-amd64

Das experimental soll Dich nicht abschrecken, die Trunk-Kernel sind die mainline-Kernel ohne Patches.
Obwohl ja, wie erwähnt, mittlerweile 5.1.4 stable ist, aber einen Versuch wäre es wert.
Passieren kann da nix...

Benutzeravatar
novalix
Beiträge: 1908
Registriert: 05.10.2005 12:32:57
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: elberfeld

Re: Buster teilweise etwas langsam

Beitrag von novalix » 24.05.2019 16:23:52

Mit buster wird apparmor für einige Dienste "scharf" geschaltet. Daher die Mehrzahl an Meldungen im Vergleich zu stretch.
Die Meldungen, die Du gepostet hast, sind aber völlig normal und sollten so auch in der "schnellen" buster installation zu lesen sein; eher unwahrscheinlich, dass sich hier der Flaschenhals verbirgt.
Meiner Meinung nach wäre es zielführender noch weitere Logs zu Rate zu ziehen, vor allem solche, die mit den grafischen Programmen zusammenhängen (z.B. Xorg) und mal versuchen zu monitoren, was denn genau passiert, wenn der Rechner lahmt (htop, iostat und so).
Das Wem, Wieviel, Wann, Wozu und Wie zu bestimmen ist aber nicht jedermannns Sache und ist nicht leicht.
Darum ist das Richtige selten, lobenswert und schön.

halo44
Beiträge: 703
Registriert: 12.05.2015 15:19:13

Re: Buster teilweise etwas langsam

Beitrag von halo44 » 24.05.2019 16:24:40

KP97 hat geschrieben: ↑ zum Beitrag ↑
24.05.2019 15:35:08
... Es gibt auch noch das Paket libpam-apparmor, das solltest Du auch deinstallieren, falls installiert ...
Das Paket ist nicht installiert.
KP97 hat geschrieben: ↑ zum Beitrag ↑
24.05.2019 15:35:08
... Seltsam aber, daß auf Deinem Notebook dieser Fehler nicht auftritt. Hast Du da mal die Parameter und Einstellungen verglichen? ...
Die Einstellungen sind die gleichen wie auch beim Desktoprechner für Buster, also
CONFIG_SECURITY_APPARMOR=y
CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE=1
CONFIG_SECURITY_APPARMOR_HASH=y
CONFIG_SECURITY_APPARMOR_HASH_DEFAULT=y
# CONFIG_SECURITY_APPARMOR_DEBUG is not set
CONFIG_DEFAULT_SECURITY_APPARMOR=y
CONFIG_DEFAULT_SECURITY="apparmor"
Allerdings hat der Notebook den Kernel 4.18.0-3. Der Desktoprechner hat den Kernel 4.19.0-5.
KP97 hat geschrieben: ↑ zum Beitrag ↑
24.05.2019 15:35:08
... Testweise könntest Du auch mal den Kernel 5.0 aus experimental installieren:
https://packages.debian.org/experimenta ... runk-amd64
Das ist eine Überlegung wert. Vielleicht auch ein Versuch mit 4.18.0-3, wenn erreichbar?

Gruss H.

halo44
Beiträge: 703
Registriert: 12.05.2015 15:19:13

Re: Buster teilweise etwas langsam

Beitrag von halo44 » 24.05.2019 16:29:50

novalix hat geschrieben: ↑ zum Beitrag ↑
24.05.2019 16:23:52
Mit buster wird apparmor für einige Dienste "scharf" geschaltet. Daher die Mehrzahl an Meldungen im Vergleich zu stretch.
Die Meldungen, die Du gepostet hast, sind aber völlig normal und sollten so auch in der "schnellen" buster installation zu lesen sein; eher unwahrscheinlich, dass sich hier der Flaschenhals verbirgt ...
Möglich, da ja der Notebook mit apparmor störungsfrei läuft.
novalix hat geschrieben: ↑ zum Beitrag ↑
24.05.2019 16:23:52
... Meiner Meinung nach wäre es zielführender noch weitere Logs zu Rate zu ziehen, vor allem solche, die mit den grafischen Programmen zusammenhängen (z.B. Xorg) und mal versuchen zu monitoren, was denn genau passiert, wenn der Rechner lahmt (htop, iostat und so).
htop hatte ich bereits versucht und dabei festgestellt, daß die Nutzung der CPU-Zeit anstieg. Auf unterschiedliche Werte, teils bis 33%. Die Memorynutzung stieg nicht an.

Gruss H.

halo44
Beiträge: 703
Registriert: 12.05.2015 15:19:13

Re: Buster teilweise etwas langsam

Beitrag von halo44 » 24.05.2019 19:43:58

Probeweise habe ich mal den Kernel 5.0 aus experimental installiert. Der Rechner läuft auch bisher offensichtlich stabil, bringt aber keine Veränderung die Verzögerungen betreffend.

Erwähnen möchte ich noch, daß ich keinen Network-Manager nutze, sondern wie schon bei Stretch systemd-networkd.

Ein long-Test mit smartctl auf die HDD brachte übrigens keine Fehler.

Gruss H.

Antworten