Tumbleweed: Probleme mit gierigen Node.js tasks

tomfrit · January 31, 2023, 9:21am

Hallo,
ich nutze Tumbleweed, Gnome3, VSCode, Sublime Merge und Chrome und habe große Probleme, dass so Nodejs mein ganzes System lahm legt. Klar, das sind sehr umfangreiche tasks (yarn, jest, großes Projekt etc) aber ganz ehrlich erinnert mich das an Windows 3.1 oder MacOS 7. Kann doch nicht sein, dass im Jahr 2023 das ganze System einfriert, weil ein Task zu gierig ist???
Hat jemand Hinweise, wie ich das debuggen und im besten Fall beheben kann?
Danke
thomas

System:
  Host: localhost.localdomain Kernel: 6.1.8-1-default arch: x86_64 bits: 64
    Desktop: GNOME v: 43.2 Distro: openSUSE Tumbleweed 20230129
Machine:
  Type: Laptop System: LENOVO product: 20T6000MGE v: ThinkPad E14 Gen 2
    serial: <superuser required>
  Mobo: LENOVO model: 20T6000MGE serial: <superuser required> UEFI: LENOVO
    v: R1AET37W (1.13 ) date: 04/09/2021
Battery:
  ID-1: BAT0 charge: 40.7 Wh (100.0%) condition: 40.7/45.0 Wh (90.5%)
CPU:
  Info: 8-core model: AMD Ryzen 7 4700U with Radeon Graphics bits: 64
    type: MCP cache: L2: 4 MiB
  Speed (MHz): avg: 1868 min/max: 1400/2000 cores: 1: 4184 2: 1863 3: 1400
    4: 1862 5: 1423 6: 1420 7: 1397 8: 1397
Graphics:
  Device-1: AMD Renoir driver: amdgpu v: kernel
  Device-2: Realtek USB Camera type: USB driver: uvcvideo
  Device-3: IMC Networks Integrated Camera type: USB driver: uvcvideo
  Display: wayland server: X.org v: 1.21.1.6 with: Xwayland v: 22.1.7
    compositor: gnome-shell driver: X: loaded: modesetting unloaded: fbdev,vesa
    dri: radeonsi gpu: amdgpu resolution: 1: 1920x1080~60Hz 2: 1920x1080~60Hz
  API: OpenGL v: 4.6 Mesa 22.3.4 renderer: AMD Radeon Graphics (renoir LLVM
    15.0.7 DRM 3.49 6.1.8-1-default)
Audio:
  Device-1: AMD Renoir Radeon High Definition Audio driver: snd_hda_intel
  Device-2: AMD ACP/ACP3X/ACP6x Audio Coprocessor driver: N/A
  Device-3: AMD Family 17h/19h HD Audio driver: snd_hda_intel
  Device-4: Plantronics Plantronics Blackwire 3220 Series type: USB
    driver: plantronics,snd-usb-audio,usbhid
  Device-5: Realtek USB MIC type: USB
    driver: hid-generic,snd-usb-audio,usbhid
  Sound API: ALSA v: k6.1.8-1-default running: yes
  Sound Server-1: PipeWire v: 0.3.65 running: yes
Network:
  Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet
    driver: r8169
  IF: enp2s0 state: up speed: 100 Mbps duplex: full mac: 90:2e:16:1f:39:e7
  Device-2: Intel Wi-Fi 6 AX200 driver: iwlwifi
  IF: wlp3s0 state: up mac: e0:2b:e9:16:64:df
  Device-3: Realtek RTL8153 Gigabit Ethernet Adapter type: USB driver: r8152
  IF: enp4s0f3u1u1 state: down mac: a0:ce:c8:f4:02:31
Bluetooth:
  Device-1: Intel AX200 Bluetooth type: USB driver: btusb
  Report: rfkill ID: hci0 state: up address: see --recommends
Drives:
  Local Storage: total: 476.94 GiB used: 58.45 GiB (12.3%)
  ID-1: /dev/nvme0n1 vendor: Toshiba model: KBG40ZNT512G MEMORY
    size: 476.94 GiB
Partition:
  ID-1: / size: 270.89 GiB used: 56.44 GiB (20.8%) fs: btrfs
    dev: /dev/nvme0n1p5
  ID-2: /boot/efi size: 256 MiB used: 37.6 MiB (14.7%) fs: vfat
    dev: /dev/nvme0n1p1
  ID-3: /home size: 270.89 GiB used: 56.44 GiB (20.8%) fs: btrfs
    dev: /dev/nvme0n1p5
  ID-4: /opt size: 270.89 GiB used: 56.44 GiB (20.8%) fs: btrfs
    dev: /dev/nvme0n1p5
  ID-5: /var size: 270.89 GiB used: 56.44 GiB (20.8%) fs: btrfs
    dev: /dev/nvme0n1p5
Swap:
  ID-1: swap-1 type: partition size: 2 GiB used: 1.98 GiB (99.0%)
    dev: /dev/nvme0n1p6
Sensors:
  System Temperatures: cpu: 73.0 C mobo: N/A gpu: amdgpu temp: 48.0 C
  Fan Speeds (RPM): fan-1: 1800 fan-2: 1800
Info:
  Processes: 493 Uptime: 2h 44m Memory: 14.85 GiB used: 12.86 GiB (86.6%)
  Shell: Bash inxi: 3.3.23

karlmistelberger · January 31, 2023, 10:15am

Da liegst du richtig. Ein Task legt keinen Rechner mit mehreren CPUs lahm. Tumbleweed verkraftet viele Tasks ohne dass es jemals einfriert: Host 6700k At Work - monitored with systemd-cgtop

Wahrscheinlich überlastest du dein Notebook.

  Swap:
  ID-1: swap-1 type: partition size: 2 GiB used: 1.98 GiB (99.0%)

Vermutlich hast du fast kein RAM. Der Swap ist auch ausgegangen. Das kann gar nichts werden.

tomfrit · January 31, 2023, 10:19am

Hallo Karl,
danke für die Antwort. Die Kiste hat 16GB RAM. Zu wenig?

karlmistelberger · January 31, 2023, 11:21am

Auf die absolute Größe kommt es nicht an, sondern auf das Verhältnis wie viel angefordert wird und wie viel vorhanden ist.

Es kann aber auch sein, dass der Swap Ärger macht. Du kannst ihn einfach ausschalten und kontrollieren ob das hilft. Letzten Sommer habe ich ein ThinkBook mit 16 GB gekauft. Das lief ohne Swap mit btrfs ganz hervorragend: Lenovo Thinkbook Windows 11 / Tumbleweed dual boot

tomfrit · January 31, 2023, 2:52pm

Danke, ich versuche mal swap auszuschalten. Vielleicht ist es auch Chrome (mit viel Teams) und/oder VS Code, die Amok laufen. Wundert mich nur, dass sich das System so in die Knie zwingen lässt.

hui · January 31, 2023, 2:55pm

Wenn der Arbeitsspeicher und der Swap vollgelaufen ist, dann zwingst du alle Systeme in die Knie egal was für eine Hardware drumherum ist. Und da gibt es viele Möglichkeiten um das sehr schnell herbeizuführen. Da brauchst du nur 40-50 Tabs auf einer Seite wie Flickr und schon schnellt dein RAM-Verbrauch durch die Decke…

tomfrit · January 31, 2023, 4:30pm

Sorry, aber das sollte so schlichtweg nicht stimmen. Das ein Programm sich so ausbreitet, dass sich kein Mauszeiger mehr bewegt und keine Möglichkeit zum Abbruch mehr besteht kenn ich so wirklich nur von MacOS7 oder Win 3.1. Sowas sollte das OS abfangen und tut es normalerweise auch. Mach mal 50 Tabs am Mac auf, irgendwann geht halt FF in die Knie, aber niemals das gesamte System.

tomfrit · February 1, 2023, 11:35am

Nachtrag: Es scheint kswapd0 zu sein, was hier durchdreht. Swap hab ich allerdings aus (swapoff -a) von daher weiß ich nicht, was der da macht …
Weiterhin freue ich mich über jeden Ratschlag und Lösungsvorschlag.

karlmistelberger · February 1, 2023, 11:58am

kswapd0 ist von swapoff -a wahrscheinlich unbeeindruckt. Neuerdings sucht, findet und aktiviert Tumbleweed vorhandene Swap-Partitionen auch dann wenn sie gar nicht in /etc/fstab aufgeführt sind.

Ich habe auf dem host 6700k nie Swap bestellt. Er ist dennoch vorhanden:

6700k:~ # free -h
               total        used        free      shared  buff/cache   available
Mem:            31Gi       1.3Gi        29Gi       186Mi       1.1Gi        29Gi
Swap:           15Gi          0B        15Gi
6700k:~ #

Eventuell muss man erst die Swap-Partition löschen und neu booten um ganz sicher zu gehen.

tomfrit · February 1, 2023, 2:44pm

Ich bin jetzt mal in die andere Richtung gelaufen und hab mir ein 16GB swapfile angelegt. Bisher läuft alles und während einiger kleiner Tests ist das neue swap bis über 50% vollgelaufen. Wird also wohl gebraucht …

karlmistelberger · February 2, 2023, 6:31am

Da bin ich nicht so sicher. Eine Anwendung fordert Speicher an und zeigt sich wenig kooperativ. Ob sie den Speicher auch braucht ist nicht ausgemacht.

tomfrit · February 2, 2023, 7:22am

Mir ist das ehrlich gesagt egal ob die Anwendung den Speicher braucht oder nur gerne hätte, solange sie mir das System nicht lahm legt

kasi042 · February 2, 2023, 10:37pm

Sorry, kommt etwas spät: Aber es scheint auch kein Wunder zu sein, dass der Swap sich füllt. Dein Speicher war auch schon ziemlich voll:

Info: Processes: 493 Uptime: 2h 44m Memory: 14.85 GiB used: 12.86 GiB (86.6%) Shell: Bash inxi: 3.3.23
Hast Du schonmal mit htop nachgesehen, welche Prozesse da noch so nach Speicher gieren? Kannst Du die vielleicht zuordnen, wenn Du mit F5 die Baumstruktur anzeigen lässt?

tomfrit · February 3, 2023, 8:45am

Danke! Ja es sind hauptsächlich Chrome und VSCode, die sich so viel Speicher gönnen. Ich hab schon eine sehr gierige VSCode Extension entfernt und bisher sieht es aus, als hätte mein swapfile die Probleme gelöst

GrandDixence2 · February 9, 2023, 10:22pm

ganz ehrlich erinnert mich das an Windows 3.1 oder MacOS 7. Kann doch nicht sein, dass im Jahr 2023 das ganze System einfriert, weil ein Task zu gierig ist???

Wenn der Linux-Administrator:in seine Hausaufgaben versäumt, verhält sich eine aktuelle Linuxinstallation genau so! Abhilfe:

cgroups mit systemd korrekt konfigurieren das keine SWAP mehr benötigt wird. Einstieg dazu bietet:

https://wiki.archlinux.org/title/Cgroups

Systemanalyse und Tuninghandbuch > Kapitel “9 - Kernel control groups”
openSUSE-Dokumentation

man systemd.resource-control
man systemd-system.conf

Nutzung der SWAP reduzieren (Swappiness). Mit den Befehlen top und ps die Speicherverwendung kontrollieren. Siehe dazu:

Viel Glück!

GrandDixence2 · February 16, 2023, 9:44pm

Ein ausartendes Userland (user.slice) kann mit ein wenig Vorbereitsarbeit:

# mkdir /etc/systemd/system/user.slice.d
# touch /etc/systemd/system/user.slice.d/99-Desktop.conf
# chown -R root:root /etc/systemd/system/user.slice.d/
# chmod u=rwx,g=rx,o=rx /etc/systemd/system/user.slice.d
# chmod u=rw,g=r,o=r /etc/systemd/system/user.slice.d/99-Desktop.conf

mit dieser Konfigurationsdatei:

################################################################################
# /etc/systemd/system/user.slice.d/99-Desktop.conf                             #
#                                                                              #
# SLED15 SP4                                                                   #
#                                                                              #
# GrandDixence, 16.02.2023                                                     #
################################################################################

[Slice]
CPUAccounting=yes
IOAccounting=yes
MemoryAccounting=yes
TasksAccounting=yes
CPUQuota=180%
MemoryHigh=50%
MemoryMax=75%
TasksMax=2000

und ein wenig Abschlussarbeit:

# yast2 bootloader
=> Zum Registerblatt "Kernel-Parameter" wechseln.
=> Im Feld "Optionale Parameter für Kernel-Befehlszeile" die Kerneloption:

systemd.unified_cgroup_hierarchy=1

ergänzen. Dann Dialogfenster über den "OK"-Knopf schliessen.

# reboot

in seine Schranken gewissen werden.

GrandDixence2 · February 17, 2023, 10:19pm

Tests mit dem mehrmaligen gleichzeitigen Starten des Speicherfresser-Shellskripts (speicherFresser.sh):

#!/bin/bash
for x in {0..69999999999}
do
    y=$x$y
done

Quelle: https://www.baeldung.com/linux/memory-overcommitment-oom-killer

zeigen auf, dass diese Konfigurationsdatei besser wirkt:

################################################################################
# /etc/systemd/system/user.slice.d/99-Desktop.conf                             #
#                                                                              #
# SLED15 SP4                                                                   #
#                                                                              #
# GrandDixence, 17.02.2023                                                     #
################################################################################

[Slice]
CPUAccounting=yes
IOAccounting=yes
MemoryAccounting=yes
TasksAccounting=yes
CPUQuota=180%
MemoryMax=80%
MemorySwapMax=0
TasksMax=2000

Nach der Änderung der Systemd-Konfigurationsdatei die Änderungen mit:

# systemctl daemon-reload

übernehmen.

Man beachte beim Lauf des Speicherfresser-Shellskripts die Ausgaben von:

# top
# systemd-cgtop
# systemctl status user.slice

Viel Glück!