Open rustamusmanov973 opened 1 year ago
I've also had this problem for years, especially when (dis)connecting USB devices. Haven't investigated it much but have had success with the solution from http://notes.secretsauce.net/notes/2016/04/08_glibc-malloc-inefficiency.html of calling malloc_trim
from the Emacs process. Reproducing their script here with minor changes to the trim call:
#!/bin/sh
# malloc-trim.sh
# From http://notes.secretsauce.net/notes/2016/04/08_glibc-malloc-inefficiency.html
set -e
PID=$1
test -n "$PID" || { echo "Need PID on the cmdline" > /dev/stderr; exit 1; }
before=`ps -h -p $PID -O rss | awk '{print $2}'`
gdb --batch-silent --eval-command 'call (int)malloc_trim(0)' -p $PID
after=`ps -h -p $PID -O rss | awk '{print $2}'`
echo "before: $before"
echo "after: $after"
echo "freed: $(($before - $after))"
Note that this is glibc-specific. It has been pretty robust when run from inside an EXWM session or another TTY when the session is unresponsive. There was a window of Emacs/userspace-stuff/kernel versions in the past when it would sometimes hose my Emacs process.
Considering that it seems to work and that Emacs' memory usage continually grows in this scenario: could it be that the device (dis)connects lead to a rapid instantiation of many short-lived objects in XELB/EXWM?
I tried to connect some devices while using exwm (with clean dotspacemacs/user-config () and some packages, including exwm installed):
htop displays processes "emacs" eating more and more RAM (quickly). RAM usage increases: smth like 2-3GB (yes, GB)/second. everything freezes. Ctrl+G doesn't seem to solve the problem. Sometimes RAM usage increases to some level and stops increasing, but remains astronomically high (like +6 GB). Sometimes tty3 (ctrl+alt+f3) works and I can kill emacs (killall emacs). I failed to find out what is happening using "Emacs Memory Debugging" article in the wiki.
OS: 5.15.81-1-MANJARO linux