4,3 GB. So viel RAM fraß mein gnome-shell Prozess, als ich ihn auf frischer Tat ertappte.
Oder: Wie ich lernte, meine GPU nicht mehr zu beschuldigen und System-Logs zu lieben
Kennste das? Dein GNOME-Desktop wird über ein paar Tage immer langsamer. Fenster-Animationen ruckeln. Die Übersicht braucht ewig zum Öffnen. Fenster ziehen fühlt sich an wie Möbel durch Honig schieben. Der offensichtliche Verdächtige? Meine NVIDIA RTX 3080 Ti, die drei hochauflösende Monitore mit zusammen 47,5 Megapixeln befeuert.
Ich lag falsch. Spektakulär falsch.
Das Setup (AKA: Die Overkill-Workstation)
Bevor wir loslegen, hier mein Setup:
- System: Ubuntu 22.04, GNOME auf X11
- CPU: Intel i7/i9 (16 Kerne)
- RAM: 64 GB
- GPU: NVIDIA RTX 3080 Ti
- Displays: 3 Monitore (2× 2560×1600 @ 200% Scaling, 1× 4K @ ~133% Scaling)
Diese Maschine sollte GNOME wie Butter verarbeiten. Stattdessen fühlte es sich nach ein, zwei Tagen Uptime an, als würde ich einen Felsbrocken bergauf schieben.
Die üblichen Verdächtigen
Wenn dein Linux-Desktop mit einer NVIDIA-GPU laggt, wo schaust du zuerst? Bei der GPU, logisch.
nvidia-smi && dpkg -l | grep nvidia-driver && ubuntu-drivers devicesErgebnis: Treiber 580.95.05 (empfohlen), CUDA 13.0, GPU läuft stabil bei 71°C, ~10 GB VRAM belegt. Nix Auffälliges.
Was ist mit der Display-Konfiguration? Vielleicht stimmt was nicht mit meinem Multi-Monitor-Setup:
xrandr --query | grep -E "connected|[0-9]+x[0-9]+\*"DP-0 connected 5120x3200+10240+0
DP-2 connected 5120x3200+0+0
DP-4 connected primary 5120x2880+5120+0Drei Displays mit hoher Auflösung. Ja, das sind 47,5 Megapixel insgesamt. Ja, Xorg nutzte 6 GB VRAM. Aber das ist normal für dieses Setup—die GPU war nicht das Problem.
Die Ermittlung: Den Brotkrumen folgen
Zeit, in die System-Logs zu schauen. Zuerst musste ich finden, wo die aktuelle Boot-Session begann:
grep -n "kernel.*Linux version" /var/log/syslogDann suchte ich nach allem GPU-bezogenen, Display-bezogenen oder Fehler-bezogenen seit dem Boot:
tail -n +<BOOT_LINE> /var/log/syslog | grep -iE "nvidia|gpu|gnome-shell|mutter|Xorg|freeze|hung|timeout|failed|error|OOM|segfault|NVRM" | head -100Keine NVIDIA Xid-Errors. Keine OOM-Events. Keine Memory-Pressure-Warnungen. GPU und RAM machten ihren Job.
Aber Moment—was ist das für ein Rauschen von gnome-shell?
Der rauchende Colt: 660+ JavaScript-Fehler
Ich filterte gezielt nach GNOME Shell JavaScript-Fehlern:
tail -n +<BOOT_LINE> /var/log/syslog | grep -iE "gnome-shell.*error|js error" | head -50Und da war es. Seite um Seite von:
Dec 1 02:01:33 mb-desktop gnome-shell[7597]: JS ERROR: TypeError: this._bgManager is null
after__init/<@/home/mb/.local/share/gnome-shell/extensions/vertical-overview@RensAlthuis.github.com/workspaceThumbnail.js:276:13
_destroyThumbnails@resource:///org/gnome/shell/ui/workspaceThumbnail.js:981:33Und dieser Kracher, 15 Mal in schneller Folge wiederholt:
Dec 1 02:01:40 mb-desktop gnome-shell[7597]: message repeated 15 times: [ JS ERROR: TypeError: this._bgManager is null... ]Ich gruppierte und zählte die Fehler:
tail -n +<BOOT_LINE> /var/log/syslog | grep -E "gnome-shell\[7597\].*JS ERROR" | cut -d']' -f2- | sort | uniq -c | sort -rn | head -20| Extension | Fehleranzahl | Fehlertyp |
|---|---|---|
| vertical-overview | 660+ | TypeError: this._bgManager is null |
| dash-to-panel | ~400 | Konflikte mit vertical-overview |
| ubuntu-dock | 14 | Impossible to enumerate trash children |
| another-window-session-manager | 6+ | GTop fehlt, Save-Fehler |
Der Schuldige: Jedes Mal wenn ich Super drückte um die Übersicht zu öffnen,
warf die vertical-overview Extension 16-24 JavaScript-Fehler. Über zwei Tage
normaler Nutzung summierten sich das auf 660+ Fehler—und offenbar eine ganze
Menge geleakten Speicher.
Die Beweislage: Memory-Analyse
Jetzt wusste ich was passierte. Zeit zu beweisen, wie schlimm es war:
ps -C gnome-shell -o rss --no-headers | awk '{sum+=$1} END {print sum/1024 " MB"}'Ausgabe: 4271 MB
Das sind 4,3 GB RAM allein für gnome-shell. Normalerweise sollten es 400-800 MB sein.
Ein Blick in die volle Prozessliste:
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
mb 7597 3.6 6.5 11176396 4271296 ? Rsl Dec01 99:27 /usr/bin/gnome-shellLäuft seit dem 1. Dezember, verbraucht 6,5% meiner 64 GB RAM, und hat 99 Minuten CPU-Zeit angesammelt—nur für gnome-shell.
Der Fix: Ein Befehl, sie alle zu knechten
Jetzt wird’s befriedigend. Du denkst vielleicht, Alt+F2 drücken, r eintippen
und Enter wäre die Lösung. Das ist der klassische GNOME Shell Neustart-Trick.
Nope. Das ist ein “Soft Restart”, der den geleakten Speicher nicht wirklich freigibt.
Der echte Fix:
killall -3 gnome-shellDas sendet SIGQUIT an gnome-shell, was einen Core-Dump auslöst und einen
echten Neustart erzwingt. Deine laufenden Anwendungen bleiben offen, aber
gnome-shell startet frisch.
Nach dem Neustart:
ps -C gnome-shell -o rss --no-headers | awk '{sum+=$1} END {print sum/1024 " MB"}'Ausgabe: 784 MB
3,5 GB sofort freigegeben. Der Desktop war wieder flüssig.
Was ich auf die harte Tour gelernt habe
1. Alt+F2 → r fixt keine Memory Leaks
Der GNOME Shell “Restart”-Befehl (r) ist eher ein Refresh. Er lädt Extensions
und UI-Elemente neu, gibt aber angesammelten Speicher nicht frei. Für echte
Memory Leaks brauchst du einen echten Prozess-Neustart.
2. Extension-Kompatibilität ist ein Minenfeld
Die Kombination aus vertical-overview und dash-to-panel war toxisch. Beide
Extensions modifizieren, wie die Übersicht und Workspaces funktionieren, und
traten sich ständig gegenseitig auf die Füße. Die Fehler kaskadierten jedes Mal,
wenn ich die Übersicht öffnete.
3. Verwaiste Extensions sind tickende Zeitbomben
Ein Blick ins vertical-overview GitHub Repository zeigte zahlreiche offene Issues zu Memory Leaks und Kompatibilitätsproblemen mit neueren GNOME-Versionen. Die Extension wird nicht mehr aktiv gepflegt.
4. Deine GPU ist vielleicht nicht das Problem
Wenn du eine fette GPU und hochauflösende Displays hast, ist es leicht, Grafik-Performance-Probleme der GPU in die Schuhe zu schieben. Aber gnome-shell ist eine JavaScript-Anwendung, die auf deiner CPU läuft, und ihre Memory Leaks haben nichts mit deiner Grafikkarte zu tun.
Der Langzeit-Fix
Option A: Problematische Extensions entfernen
gnome-extensions disable vertical-overview@RensAlthuis.github.com
gnome-extensions disable dash-to-panel@jderose9.github.comWenn du eine vertikale Übersicht brauchst, such nach aktiv gewarteten Alternativen oder warte, bis GNOME das nativ implementiert.
Option B: Einen Restart-Alias erstellen
Wenn du an deinen Extensions hängst und bereit bist, regelmäßige Wartung zu machen:
# In ~/.bashrc einfügen
alias gnome-restart='killall -3 gnome-shell'Ausführen, wann immer’s anfängt zu ruckeln. Nicht elegant, aber effektiv.
Option C: Überwachen und warnen
Richte einen simplen Cron-Job ein, der dich warnt, wenn gnome-shell zu gierig wird:
# Jede Stunde prüfen, warnen wenn gnome-shell über 2GB liegt
0 * * * * MEM=$(ps -C gnome-shell -o rss --no-headers | awk '{sum+=$1} END {print sum/1024}'); [ $(echo "$MEM > 2000" | bc) -eq 1 ] && notify-send "gnome-shell nutzt ${MEM}MB"Diagnose-Befehle Spickzettel
Hier ist alles, was du brauchst, um deine eigenen gnome-shell Probleme zu untersuchen:
# System-Info
nvidia-smi && dpkg -l | grep nvidia-driver
xrandr --query
# Boot-Zeile im Syslog finden
grep -n "kernel.*Linux version" /var/log/syslog
# Nach Fehlern seit Boot suchen
tail -n +<LINE> /var/log/syslog | grep -iE "gnome-shell.*error|js error"
# Fehler gruppieren und zählen
tail -n +<LINE> /var/log/syslog | grep -E "gnome-shell.*JS ERROR" | cut -d']' -f2- | sort | uniq -c | sort -rn | head -20
# gnome-shell Memory-Verbrauch prüfen
ps -C gnome-shell -o rss --no-headers | awk '{sum+=$1} END {print sum/1024 " MB"}'
# Memory-Verbrauch kontinuierlich überwachen
watch -n 5 "ps -C gnome-shell -o rss --no-headers | awk '{sum+=\$1} END {print sum/1024 \" MB\"}'"
# Der Fix
killall -3 gnome-shellDie Transformation
| Vorher | Nachher |
|---|---|
| 4,3 GB RAM | 784 MB RAM |
| Ruckelnde Animationen | Butterweich |
| GPU beschuldigt | Echten Übeltäter gefunden |
| Stunden der Verwirrung | Ein-Befehl-Fix |
Fazit
Wenn dein GNOME-Desktop das nächste Mal zäh wird, greif nicht sofort zu GPU-Treibern oder Display-Einstellungen. Check zuerst deine Extensions. Diese praktischen kleinen Add-ons, die deinen Workflow anpassen, könnten auch langsam dein System auffressen.
Und wenn du vertical-overview nutzt—vielleicht ist es Zeit, Lebewohl zu sagen.
Welche Extensions haben euch schon mal verbrannt? Ich würde gerne eure GNOME-Horrorgeschichten hören.