5

For linux (Ubuntu, Debian, etc), different desktop environments cost different amounts of resources (RAM). Gnome and KDE tend to cost more RAM than others like XFCE / LXDE / LXQT:

https://unihost.com/help/how-to-choose-linux-desktop-environment-ram-usage/

I am wondering if I don't log in via the GUI of the desktop environment, and only use ssh to interact with the OS, do the RAM usages by these desktop environments still make a difference?

For example, I have a Debian Gnome and a Debian XFCE. After turning on the two machines, I only use SSH to interact with them. In this case, do they use the same amount of RAM?

5
  • In this case, do they use the same amount of RAM? Yes. Feb 18 at 8:20
  • 1
    @ArtemS.Tashkinov I'm curious as to the reasoning behind the statement that in bringing up different desktop environments the RAM usage is the same. The presentation of a login screen may be similar but the background processes are very different for Xfce/LXDE/Gnome/KDE/Cinnamon so I would be surprised that all of these had the same memory footprint.
    – doneal24
    Feb 18 at 21:57
  • 2
    @doneal24 If you never log in to a desktop session, nothing gets started that is specific to the desktop environment unless you count the display manager or greeter. There are differences in reality though, but it’s because some display managers/greeters use more memory than others. Feb 19 at 3:15
  • 3
    When you're not logged in, DE background services are not running. And if they are something is terribly wrong. Feb 19 at 9:13
  • If nobody uses the GUI there is no need to start one in the first place (not even the login screen with its underlying infrastructure). A typical server system (where no graphical login is used) would often run with no living soul in close proximity; for maintenance, it would have just a text terminal for a local login. If set up properly, one could still initiate a graphic UI session (a generation ago, years ago one would do that by typing startx). Feb 19 at 12:48

1 Answer 1

13

If there is no GUI session used, but the system still displays a GUI for login, only this GUI login part will use memory. Processes managing this are mostly waiting and thus mostly doing nothing. If swap if enabled (something to ponder if the only disks available are SSD that have to be preserved from wearing off, anyway this answer is not about deciding this), parts of the process(es) doing nothing will be swapped out when more memory becomes needed, thus further limiting the memory footprint of the GUI.

To answer the question: using SSH won't affect GUI parts currently in use. The comparison is about the currently loaded and running parts. On a typical Debian installation, choosing Gnome gets GDM (Gnome Display Manager) for GUI login prompt, choosing XFCE gets LightDM (Lightweight Display Manager) for GUI login prompt. I would tend to say that LightDM (and thus XFCE) will use less memory. For both cases, most of it (not all, nor active parts, such as displaying the time) would be swapped out if there is swap, but without it all of it will stay in physical RAM.

Testing in a Debian 12 amd64 VM without swap, accessed through SSH and doing nothing else than providing an SSH service and offering a GUI login prompt or none, the used memory measured with free -m on the VM right after echo 3 > /proc/sys/vm/drop_caches was along a few reboots:

GDM: ~ 494-506MB
LightDM: ~ 324-331MB

neither (console-only): ~ 196-214MB

I'm sure there can be variations, but overall LightDM, and thus meaning having chosen to install XFCE, appears to use less memory than GDM and thus having chosen to install Gnome.

Both were installed, then were switched or disabled as described below and then rebooted.


Now you can also use GDM to start XFCE or use LightDM to start Gnome to further murky this point, but I believe both might loose some parts of their integration to their default manager, such as issues when locking screen or switching user which would have to be further tinkered with. On Debian to switch between them (possibly not instantaneously but only for next start) if both are installed that would be either of:

dpkg-reconfigure gdm3
dpkg-reconfigure lightdm

to get prompted (a reboot or equivalent might be needed after this or some operations below).


The best way to not use such memory is to disable completely the start of the GUI: that's what is done on most server-only systems: even when they have a video card and are able still to display on their console output, they are usually set to not display any GUI, among other reasons to spare resources, especially memory. If that's what you intend, you can do it now, without uninstalling anything yet, and still change your mind later. On Debian, for GDM this is described on this Debian wiki: GDM - Controlling the GDM daemon:

systemctl set-default multi-user.target

This also applies to LightDM.

One can still reconsider and enable them back with either:

systemctl set-default graphical.target

Or start one of them only once without enabling them back at startup:

systemctl start gdm
systemctl start lightdm
3
  • It's a bit silly that just having GDM running takes another 300MB of RAM. Honestly, even the LightDM memory usage (130M) surprises me...
    – marcelm
    Feb 18 at 15:46
  • 3
    To follow up on this, in configuring a server I not only do not enable the start of the GUI desktop but I don't install it in the first place. Savings are not only in RAM usage but also in disk usage (minimal) and in keeping all packages current and not in conflict with other necessary packages.
    – doneal24
    Feb 18 at 21:50
  • @marcelm: high rez bitmap graphics take space, and the X server is optimized for high performance, not low memory usage. And it probably memory-maps some of video RAM, although that probably doesn't count as part of its working set (RSS). But yeah the greeter itself could and arguably should be optimized for low memory usage, since it spends most of its time just sitting there. But people would rather write them with complex GUI libraries. At least we've finally passed the point where GUIs and web browsers expand to fill any/all available space and CPU horsepower on typical desktops. Feb 19 at 6:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .