4.3 GB. That’s how much RAM my gnome-shell process was eating when I finally caught it red-handed.
Or: How I Learned to Stop Blaming My GPU and Love System Logs
My GNOME desktop had been getting progressively slower over the past few days. Window animations stuttered. The overview took forever to open. Dragging windows felt like moving furniture through molasses. The obvious suspect? My NVIDIA RTX 3080 Ti driving three high-resolution monitors at a combined 47.5 megapixels.
I was wrong. Spectacularly wrong.
The Setup (AKA: The Overkill Workstation)
Before we dive in, here’s what I’m working with:
- System: Ubuntu 22.04, GNOME on X11
- CPU: Intel i7/i9 (16 cores)
- RAM: 64 GB
- GPU: NVIDIA RTX 3080 Ti
- Displays: 3 monitors (2× 2560×1600 @ 200% scaling, 1× 4K @ ~133% scaling)
This machine should handle GNOME like a hot knife through butter. Instead, after a day or two of uptime, it felt like pushing a boulder uphill.
The Usual Suspects
When your Linux desktop gets laggy with an NVIDIA GPU, where do you look first? The GPU, obviously.
nvidia-smi && dpkg -l | grep nvidia-driver && ubuntu-drivers devicesResult: Driver 580.95.05 (recommended), CUDA 13.0, GPU running stable at 71°C, ~10 GB VRAM in use. Nothing unusual.
What about the display configuration? Maybe something’s misconfigured with my 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+0Three displays at high resolution. Yes, that’s 47.5 megapixels in total. Yes, Xorg was using 6 GB of VRAM. But that’s expected for this setup—the GPU wasn’t the problem.
The Investigation: Following the Breadcrumbs
Time to dig into the system logs. First, I needed to find where the current boot session started:
grep -n "kernel.*Linux version" /var/log/syslogThen I searched for anything GPU-related, display-related, or error-related since 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 -100No NVIDIA Xid errors. No OOM events. No memory pressure warnings. The GPU and RAM were doing fine.
But wait—what’s all this noise from gnome-shell?
The Smoking Gun: 660+ JavaScript Errors
I filtered specifically for GNOME Shell JavaScript errors:
tail -n +<BOOT_LINE> /var/log/syslog | grep -iE "gnome-shell.*error|js error" | head -50And there it was. Page after page of:
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:33And this gem, repeated 15 times in quick succession:
Dec 1 02:01:40 mb-desktop gnome-shell[7597]: message repeated 15 times: [ JS ERROR: TypeError: this._bgManager is null... ]I grouped and counted the errors:
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 | Error Count | Error Type |
|---|---|---|
| vertical-overview | 660+ | TypeError: this._bgManager is null |
| dash-to-panel | ~400 | Conflicts with vertical-overview |
| ubuntu-dock | 14 | Impossible to enumerate trash children |
| another-window-session-manager | 6+ | Missing GTop, save errors |
The culprit: Every single time I pressed the Super key to open the overview,
the vertical-overview extension threw 16-24 JavaScript errors. Over two days
of normal usage, that added up to 660+ errors—and apparently, a whole lot of
leaked memory.
The Evidence: Memory Analysis
Now I knew what was happening. Time to prove how bad it was:
ps -C gnome-shell -o rss --no-headers | awk '{sum+=$1} END {print sum/1024 " MB"}'Output: 4271 MB
That’s 4.3 GB of RAM for gnome-shell alone. Normal consumption should be 400-800 MB.
Looking at the full process list:
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-shellRunning since December 1st, consuming 6.5% of my 64 GB RAM (on a machine with 64 GB!), and accumulating 99 minutes of CPU time just for gnome-shell.
The Fix: One Command to Rule Them All
Here’s where it gets satisfying. You might think pressing Alt+F2, typing r,
and pressing Enter would fix it. That’s the classic GNOME Shell restart trick.
Nope. That’s a “soft restart” that doesn’t actually release the leaked memory.
The real fix:
killall -3 gnome-shellThis sends SIGQUIT to gnome-shell, causing it to dump core and restart
properly. Your running applications stay open, but gnome-shell gets a fresh
start.
After the restart:
ps -C gnome-shell -o rss --no-headers | awk '{sum+=$1} END {print sum/1024 " MB"}'Output: 784 MB
3.5 GB freed instantly. The desktop was smooth again.
What I Learned the Hard Way
1. Alt+F2 → r Doesn’t Fix Memory Leaks
The GNOME Shell “restart” command (r) is really more of a refresh. It reloads
extensions and UI elements but doesn’t release accumulated memory. For actual
memory leaks, you need a real process restart.
2. Extension Compatibility Is a Minefield
The combination of vertical-overview and dash-to-panel was toxic. Both
extensions modify how the overview and workspaces work, and they stepped on each
other constantly. The errors cascaded every time I opened the overview.
3. Abandoned Extensions Are Ticking Time Bombs
Checking the vertical-overview GitHub repository, I found numerous open issues about memory leaks and compatibility problems with newer GNOME versions. The extension isn’t actively maintained anymore.
4. Your GPU Might Not Be the Problem
When you have a beefy GPU and high-resolution displays, it’s easy to blame graphics performance issues on the GPU. But gnome-shell is a JavaScript application running on your CPU, and its memory leaks have nothing to do with your graphics card.
The Long-Term Fix
Option A: Remove the Problematic Extensions
gnome-extensions disable vertical-overview@RensAlthuis.github.com
gnome-extensions disable dash-to-panel@jderose9.github.comIf you need a vertical overview, look for actively maintained alternatives or wait for GNOME to implement it natively.
Option B: Create a Restart Alias
If you’re attached to your extensions and willing to do periodic maintenance:
# Add to ~/.bashrc
alias gnome-restart='killall -3 gnome-shell'Run it whenever things start feeling sluggish. Not elegant, but effective.
Option C: Monitor and Alert
Set up a simple cron job to warn you when gnome-shell gets too greedy:
# Check every hour, warn if gnome-shell exceeds 2GB
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 using ${MEM}MB"Diagnostic Command Cheatsheet
Here’s everything you need to investigate your own gnome-shell issues:
# System info
nvidia-smi && dpkg -l | grep nvidia-driver
xrandr --query
# Find boot line in syslog
grep -n "kernel.*Linux version" /var/log/syslog
# Search for errors since boot
tail -n +<LINE> /var/log/syslog | grep -iE "gnome-shell.*error|js error"
# Group and count errors
tail -n +<LINE> /var/log/syslog | grep -E "gnome-shell.*JS ERROR" | cut -d']' -f2- | sort | uniq -c | sort -rn | head -20
# Check gnome-shell memory usage
ps -C gnome-shell -o rss --no-headers | awk '{sum+=$1} END {print sum/1024 " MB"}'
# Monitor memory usage continuously
watch -n 5 "ps -C gnome-shell -o rss --no-headers | awk '{sum+=\$1} END {print sum/1024 \" MB\"}'"
# The fix
killall -3 gnome-shellThe Transformation
| Before | After |
|---|---|
| 4.3 GB RAM | 784 MB RAM |
| Stuttering animations | Butter-smooth |
| Blamed the GPU | Found the real culprit |
| Hours of confusion | One command fix |
Wrapping Up
The next time your GNOME desktop feels sluggish, don’t immediately reach for GPU drivers or display settings. Check your extensions first. Those convenient little add-ons that customize your workflow might also be slowly eating your system alive.
And if you’re using vertical-overview—maybe it’s time to say goodbye.
What extensions have burned you? I’d love to hear your GNOME horror stories.