Xorg server uses unacceptably large amounts of memory (and keep growing) when LibreOffice is running

Bug #1884850 reported by Wirawan Purwanto
22
This bug affects 3 people
Affects Status Importance Assigned to Milestone
libreoffice (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Description: Xorg server uses unacceptably large amounts of memory (and keep growing)

Ever since I upgraded to Ubuntu 20.04 (with fresh install) on my laptop (Lenovo T450s, Intel Core i5-5200U, Intel HD5500 graphics), I have been troubled by the way Xorg process uses memory.

Here is an example of memory usage of Xorg as a function of time. I rebooted the laptop on June 17:

    Xorg-usage-20200617a.txt:root 1224 1.9 0.8 948408 98848 tty7 Rsl+ 10:38 0:05 \_ /usr/lib/xorg/Xorg -core :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
    Xorg-usage-20200617b.txt:root 1224 2.2 0.8 978264 105180 tty7 Ssl+ 10:38 0:22 \_ /usr/lib/xorg/Xorg -core :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
    Xorg-usage-20200618a.txt:root 1224 0.3 1.3 1143064 162584 tty7 Ssl+ Jun17 3:15 \_ /usr/lib/xorg/Xorg -core :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
    Xorg-usage-20200619a.txt:root 1224 0.3 2.9 1432232 360700 tty7 Ssl+ Jun17 12:30 \_ /usr/lib/xorg/Xorg -core :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
    Xorg-usage-20200619b.txt:root 1224 0.3 2.7 1313120 338656 tty7 Ssl+ Jun17 12:39 \_ /usr/lib/xorg/Xorg -core :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
    Xorg-usage-20200623a.txt:root 1224 0.3 6.0 1944364 738596 tty7 Ssl+ Jun17 31:55 \_ /usr/lib/xorg/Xorg -core :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch

The filename indicates the date the "ps fuxa" command was run.
Contrast this against the memory usage of another Xorg process run for XPRA:

    Xorg-usage-20200617b.txt:wirawan 4452 2.4 2.0 1106920 244984 ? Ssl 10:46 0:12 \_ /usr/lib/xorg/Xorg-for-Xpra-:100 -noreset -novtswitch -nolisten tcp +extension GLX +extension RANDR +extension RENDER -auth /home/wirawan/.Xauthority -logfile /run/user/1000/xpra/Xorg.:100.log -configdir /run/user/1000/xpra/xorg.conf.d/4451 -config /etc/xpra/xorg.conf -depth 24 :100
    Xorg-usage-20200618a.txt:wirawan 4452 0.2 2.0 1108572 246616 ? Ssl Jun17 2:25 \_ /usr/lib/xorg/Xorg-for-Xpra-:100 -noreset -novtswitch -nolisten tcp +extension GLX +extension RANDR +extension RENDER -auth /home/wirawan/.Xauthority -logfile /run/user/1000/xpra/Xorg.:100.log -configdir /run/user/1000/xpra/xorg.conf.d/4451 -config /etc/xpra/xorg.conf -depth 24 :100
    Xorg-usage-20200619a.txt:wirawan 4452 0.2 2.0 1112460 249516 ? Ssl Jun17 8:34 \_ /usr/lib/xorg/Xorg-for-Xpra-:100 -noreset -novtswitch -nolisten tcp +extension GLX +extension RANDR +extension RENDER -auth /home/wirawan/.Xauthority -logfile /run/user/1000/xpra/Xorg.:100.log -configdir /run/user/1000/xpra/xorg.conf.d/4451 -config /etc/xpra/xorg.conf -depth 24 :100
    Xorg-usage-20200619b.txt:wirawan 4452 0.2 2.0 1112964 250020 ? Ssl Jun17 8:40 \_ /usr/lib/xorg/Xorg-for-Xpra-:100 -noreset -novtswitch -nolisten tcp +extension GLX +extension RANDR +extension RENDER -auth /home/wirawan/.Xauthority -logfile /run/user/1000/xpra/Xorg.:100.log -configdir /run/user/1000/xpra/xorg.conf.d/4451 -config /etc/xpra/xorg.conf -depth 24 :100
    Xorg-usage-20200623a.txt:wirawan 4452 0.1 2.0 1113092 250544 ? Ssl Jun17 11:22 \_ /usr/lib/xorg/Xorg-for-Xpra-:100 -noreset -novtswitch -nolisten tcp +extension GLX +extension RANDR +extension RENDER -auth /home/wirawan/.Xauthority -logfile /run/user/1000/xpra/Xorg.:100.log -configdir /run/user/1000/xpra/xorg.conf.d/4451 -config /etc/xpra/xorg.conf -depth 24 :100

My desktop usage pattern:

* MATE desktop
* 4-desktop setting (standard default MATE when shipped)
* GNUCASH
* about 3 windows of terminal (each about 5-10 tabs)
* XPRA running Firefox web browser (to isolate web browser pixmap memory usage, if that was the culprit)
* LibreOffice (several windows open at any time)
* using "redshift" to change the desktop color to red at night

I have never seen this before using Ubuntu 20.04 on this machine.
Before, when I was running Debian 8, I could run this machine for months literally without Xorg memory bloating rapidly like this (but then I was using xfce instead of MATE).
I viewed the output of xrestop, the pixmap memory usage is dominated by marco and wnck-applet:

    xrestop - Display: localhost
       Monitoring 36 clients. XErrors: 0
       Pixmaps: 110748K total, Other: 84K total, All: 110833K total

    res-base Wins GCs Fnts Pxms Misc Pxm mem Other Total PID Identifier
    1000000 20 5 2 27 1701 70198K 42K 70241K 2585 marco
    1c00000 9 4 0 9 56 30428K 1K 30430K 2612 wnck-applet
    1400000 8 4 1 21 116 3134K 4K 3138K 2603 Desktop
    0000000 2 0 2 0 178 2700K 6K 2706K ? <unknown>
    3e00000 0 0 0 1 0 2700K 0B 2700K ? <unknown>
    3a00000 17 3 1 8 92 1024K 3K 1027K 3728 (terminal)

In the previous boot (starting May 27 and ending June 17), the XOrg memory consumption grew to 1.7 GB total.

I don't know exactly which software is responsible to cause this problem, so I started out with xorg server.

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: xserver-xorg-core 2:1.20.8-2ubuntu2.1
ProcVersionSignature: Ubuntu 5.4.0-37.41-generic 5.4.41
Uname: Linux 5.4.0-37-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.11-0ubuntu27.3
Architecture: amd64
BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
CasperMD5CheckResult: skip
CompositorRunning: None
CurrentDesktop: MATE
Date: Tue Jun 23 18:47:52 2020
DistUpgraded: Fresh install
DistroCodename: focal
DistroVariant: ubuntu
ExtraDebuggingInterest: Yes
GraphicsCard:
 Intel Corporation HD Graphics 5500 [8086:1616] (rev 09) (prog-if 00 [VGA controller])
   Subsystem: Lenovo HD Graphics 5500 [17aa:5036]
MachineType: LENOVO 20BXCTO1WW
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-37-generic root=UUID=4eafd225-50c7-46d9-b3f9-7982493a300d ro quiet splash vt.handoff=7
SourcePackage: xorg-server
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 12/23/2015
dmi.bios.vendor: LENOVO
dmi.bios.version: JBET55WW (1.20 )
dmi.board.asset.tag: Not Available
dmi.board.name: 20BXCTO1WW
dmi.board.vendor: LENOVO
dmi.board.version: 0B98417 PRO
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: None
dmi.modalias: dmi:bvnLENOVO:bvrJBET55WW(1.20):bd12/23/2015:svnLENOVO:pn20BXCTO1WW:pvrThinkpadT450s:rvnLENOVO:rn20BXCTO1WW:rvr0B98417PRO:cvnLENOVO:ct10:cvrNone:
dmi.product.family: Thinkpad T450s
dmi.product.name: 20BXCTO1WW
dmi.product.sku: LENOVO_MT_20BX_BU_Think_FM_Thinkpad T450s
dmi.product.version: Thinkpad T450s
dmi.sys.vendor: LENOVO
version.compiz: compiz N/A
version.libdrm2: libdrm2 2.4.101-2
version.libgl1-mesa-dri: libgl1-mesa-dri 20.0.4-2ubuntu1
version.libgl1-mesa-glx: libgl1-mesa-glx 20.0.4-2ubuntu1
version.xserver-xorg-core: xserver-xorg-core 2:1.20.8-2ubuntu2.1
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20200226-1
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1

Revision history for this message
Wirawan Purwanto (wirawan0) wrote :
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

I suggest trying a different desktop environment with the same apps for a while, so we can see if MATE/Marco is the main factor.

Revision history for this message
Wirawan Purwanto (wirawan0) wrote :

Thanks. I am testing XFCE desktop for now. Will report to you again once I can gather the stats better.

Changed in marco (Ubuntu):
status: New → Incomplete
Changed in xorg-server (Ubuntu):
status: New → Incomplete
Revision history for this message
Wirawan Purwanto (wirawan0) wrote :

Thanks. I am testing XFCE desktop for now.

A brief comment on XFCE experience. The starting size of Xorg process under XFCE is ~100-130 MB, but after 10 days of usage with mostly Firefox & terminal windows (multiple windows for each app, and sometimes pdf viewer [atril]) it grew to 270-300 MB. I have some data collected by xrestop, ps, if you want it. Let me know what kind of data would help.

In a prior session where I was still using LibreOFfice (again, with multiple windows, but nothing is a huge document or complicated doc with lots of graphics), the memory usage grew to over 800 MB usage. And xrestop indicated libreoffice was consuming nearly 200 MB of pixmap memory just before I closed it!

Any direction to help narrow down the source of large memory consumption would be appreciated.

Wirawan

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

After such a long period of time you are likely experiencing multiple leaks from multiple apps. You would need to do exhaustive testing with a single app over a long period to narrow down which is to blame. It's probably not worth it, but maybe you can identify the most problematic apps given more time...

Regardless, it sounds like the source of your leaks is not marco or Xorg. So I will mark those tasks as Invalid. But that doesn't mean this issue is closed. Feel free to add any apps you suspect to the top of this bug.

Changed in marco (Ubuntu):
status: Incomplete → Invalid
Changed in xorg-server (Ubuntu):
status: Incomplete → Invalid
Revision history for this message
Wirawan Purwanto (wirawan0) wrote :

Hi Daniel, responding to your comment:

In my years of using Linux desktop (in particular, XFCE), I have never experienced memory explosion caused by Xorg server like what I described in this bug report. Please allow me to be a bit candid here. It seems like the newer versions of desktop software (which could mean one or more of these: Xorg, firefox, Libre Office, XFCE and/or MATE, ...) leads to significant bloat in memory usage. This is to the point that a very capable laptop (with >= 8 GB of RAM) would perform poorly because of memory thrashing today even when our usage pattern is not changed over the years (at least I feel so). I'll back this up below.

I still have a desktop computer running Debian 8 and XFCE. Here are some stats on that running system:

* up time = 31

*

Revision history for this message
Wirawan Purwanto (wirawan0) wrote :

Please ignore #6. I clicked "Post" too soon. I will complete it and re-post.

Changed in libreoffice (Ubuntu):
status: New → Invalid
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Reopened because there's probably still a bug somewhere. Although this bug is now assigned to xorg-server I don't actually think Xorg is to blame. Xorg just owns the memory that applications have requested resources within.

The Bug Description shows Xorg's RSS creeping over 700MB which does sound like a bug. However xrestop does not seem to explain it, as that only shows 110MB of usage.

The next step here is for you to figure out exactly which app is causing the leakage. To test each app, please log out and in again, then leave just one app running overnight and nothing else.

Changed in xorg-server (Ubuntu):
status: Invalid → New
no longer affects: libreoffice (Ubuntu)
no longer affects: marco (Ubuntu)
Changed in xorg-server (Ubuntu):
status: New → Incomplete
Revision history for this message
Wirawan Purwanto (wirawan0) wrote :

Will do shortly.

Revision history for this message
Wirawan Purwanto (wirawan0) wrote :

Brief comment. Have restarted X server 3 days ago to run pretty much just Firefox + MATE terminal. Will let you know later how this goes. So far the X server memory usage (RSS) is about 125-130MB. Which is high, but not super terrible. Usually it takes a few more days before the usage swells.

Another comment, xfwm4 is using quite a bit of X pixmap memory (50-54 MB as reported by xrestop). I have 4 desktops, and the laptop display ix FHD 1920x1080. I wonder if window image caching is what causing this. When it started it measured already at 30MB.

Revision history for this message
Wirawan Purwanto (wirawan0) wrote :

While the data collection above is going on... here is a recap of the
previous X session (2020-07-05 thru 2020-08-10)

* Restarted X server with XFCE.
* Apps used almost all the time: mostly Firefox, MATE terminal
* Apps used sometimes: VLC, "xpra attach", geeqie
* Apps used rarely: libreoffice

I have collected a number of "ps fuxa" outputs which I distilled below
only to show the VSIZE and RSS for that Xorg xserver process:

~~~
2020-07-05 22:39:08 907048 88500
2020-07-05 22:42:24 950740 129288 libreoffice
2020-07-08 15:13:30 1199296 250108 libreoffice
2020-07-11 21:55:10 1227060 277484 libreoffice (vlc started after this)
2020-07-13 12:16:53 1217636 271656 vlc
2020-07-15 12:40:25 1234728 293524 vlc
2020-07-17 23:24:01 1906196 940544 vlc(163655) (2GB mem usage, terminated)
2020-07-19 20:19:16 2217016 1046988 vlc(357305)
2020-07-20 13:09:06 2235980 1071448 vlc
2020-07-22 13:18:05 2296896 819008 vlc
2020-07-22 13:36:04 2292208 862640
2020-07-22 13:36:47 2259436 860288
2020-07-22 14:07:13 2201380 923184
2020-07-30 00:53:51 2257172 1153128
2020-08-02 20:57:49 2213628 1178836
2020-08-03 11:54:58 2250960 1182832 vlc(793990)
2020-08-08 10:35:37 2493120 1526196
~~~

Note: I also filed another bug originally against VLC--because where
you saw the large memory usage above, VLC also showed memory
explosion.

https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1888558

Since that time it was re-attributed to MESA driver.
Looking at the pattern above, there is a strong likelihood that
VLC/MESA is one of the culprits for large X memory consumption.

Changed in xorg-server (Ubuntu):
status: Incomplete → New
Revision history for this message
Wirawan Purwanto (wirawan0) wrote :

I have tested two applications so far...

1) firefox + MATE terminal
2) xpra + MATE terminal

I'm sorry I can't not use MATE terminal because I still have to use part of the laptop for work.
In either case I did not notice too significant a memory growth. Again, the memory usage numbers mentioned below are the "RSS" reported by "ps".

In the case of Firefox: memory usage is approximately ~130MB (I belive this was right after Firefox was started and fully running) to over ~150 MB after 7-8 days of use. But I tried this: I closed Firefox, the memory usage dropped to below 90 MB. So at least I know that Firefox X memory seems to be released.

In the case of running xpra: before xpra is running (right after X server restart), X server memory usage is about 80 MB, and it goes up to ~120-130 MB after 3 days. It dropped back to 96MB. I don't fully know why this yet. Maybe there is some leak, but I also want to note that xfwm4 is uses significant amount of X memory. In this case and previous case, I also note that the xrestop reports increasing memory usage of "xfwm4" over time. Initially when the Xserver just restarted, xfwm4 uses ~30 MB of X memory. It goes up and down, seemingly dependent on how many windows are opened. So, no conclusion yet on that end. Note: I am running gnucash (or gnucash and firefox) on the XPRA server. I tend to think that the stuff I run under XPRA will to a good degree not affect the xserver being diagnosed except by the number of windows it displays.

I have currently been running libreoffice on the existing session (xpra+MateTerm) just to find out how things are. I have personally suspected libreoffice and/or vlc. So far, libreoffice seems to exhibit this apparent behavior: when I am actively using it, the X server RSS goes up. But when I leave that libreoffice window alone, the RSS does not increase. I'll have to re-test this by itself and report back.

Revision history for this message
Wirawan Purwanto (wirawan0) wrote :
Download full text (3.3 KiB)

Update 20200922

I have tested LibreOffice for a while.
It did cause Xorg memory explosion again as explained below.
I am excerpting my own personal notes here, please bear with the rough form of it.
The graph that I will attach next will show the point.

I started using a LibreOFfice program at 2020-09-06; this was a relaunch after
the last comment.

At timestamp = 20200921T2330, I checked Xorg memory usage tonight
after leaving LibreOffice open for over 11 days: Xorg RSS became
swollen to over 1 GB!

    xorg RSS ... 1182768 kiB

The "free" status was terrible:

                  total used free shared buff/cache available
    Mem: 12144888 9761024 596696 710552 1787168 1353420
    Swap: 1808384 1477752 330632

Three major users of Xorg memory:

    LibreOffice Writer ( PID:1760594 ):
            pixmap bytes : 334753205
    1 - xfwm4 ( PID:1477670 ):
            pixmap bytes : 141633828
    Mozilla Firefox ( PID:1816946 ):
            pixmap bytes : 44090522

The total of all three is ~520 MB.
LibreOffice alone is eating up over 334 MB of RAM!

NOTE: I did not use LibreOffice every day on this machine.
But I left that program open since it was opened on Sept 6.
I used the LO Writer occasionally to make notes now and then.

Now I am closing the LibreOffice program, see what happened.
Before LibreOffice doc was closed, the mem usage status was:

   LibreOffice pixmap bytes usage dropped to 286360981 (pixmap bytes)
   xfwm4 .... 131834529 (pixmap bytes)
   firefox .... 44090522 (pixmap bytes)
   xorg RSS .... 1203568 kiB => misleading, too much dumped to swap!

Let's close LibreOffice; after closing (time marker = 20200922T0006) the usage:

   xfwm4 .... 98517409
   firefox .... 44090522
   xorg RSS .... 1192256 kiB

A few observations:

* As you can see above, xorg RSS was NOT significantly reduced even after I closed
  the LibreOffice. That was not the case with Firefox or with Xpra;
  the memory usage dropped as soon as I closed those programs.

* I also remember from my past observations that *when this Xorg
  memory explosion occurred*, the RSS of the xorg server is way higher than the (rough) sum total of the pixmap memory consumption
  reported by xrestop.
  My fuzzy memory has it at about a factor of 4:

      RSS(Xorg) ~ 4x sum(pixmap bytes reported by xrestop)

  The example above did not quite support that though, but still, it
  is a factor of more than two!

* I also looked at smaps:
  (ref: smaps-1600747980-20200922T001300.txt).
  That file indicates the largest memory occupied is in the heap:

      $ grep -e '^[0-9a-f]' -e 'Dirty' smaps-1600747980-20200922T001300.txt
      ...
      55aa90005000-55aad31ae000 rw-p 00000000 00:00 0 [heap]
      Shared_Dirty: 0 kB
      Private_Dirty: 1078916 kB
      ...

Now I closed Firefox as well: (after closure, timestamp: 20200922T0034)

   xfwm4 .... 61755763
   xorg R...

Read more...

Revision history for this message
Wirawan Purwanto (wirawan0) wrote :
Revision history for this message
Wirawan Purwanto (wirawan0) wrote :

Based on my experience above, I can say with good degree of certainty that the LibreOffice was the culprit. I will restart the entire machine and try this again one more time.

Wirawan

summary: Xorg server uses unacceptably large amounts of memory (and keep growing)
+ when LibreOffice is running
no longer affects: xorg-server (Ubuntu)
Revision history for this message
Wirawan Purwanto (wirawan0) wrote :

Here is a fuller analysis (see next attachment, Xfce-session-20200922-analysis.html). I started LibreOffice on 9/22 nearly exclusively on a new Xfce session. (Except for the MATE terminal app, again). I edited a few documents, as indicated in the analysis. Every time without exception, the X pixmap memory usage grew. My previous attachment (graph) showed that the X memory usage eventually exploded after an extended period of time the LO Writer app was open--nearly a month. This time, I did not do that. But I managed to show in the graph that almost every document edit leads to a significant increase in the X pixmap memory usage (5 MB, 10 MB, and even 20 MB just looking at the graph). The problem is, once the LibreOffice is closed, the X pixmap memory usage won't shrink anymore. I do have the xrestop snapshots of the LibreOffice usage but haven't had chance to process the data to graph it. Ask me if that is desired. But I will send the script that polls the memory usage as a second attachment in case that is useful for others to monitor the memory growth.

Revision history for this message
Wirawan Purwanto (wirawan0) wrote :

HTML rendering of Jupyter notebook that shows the X server memory usage analysis for 2020-09-22.

Revision history for this message
Wirawan Purwanto (wirawan0) wrote :
tags: added: performance
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in libreoffice (Ubuntu):
status: New → Confirmed
Revision history for this message
DaveQB (david-dward) wrote :

I have this same issue πŸ™‹β€β™‚οΈ
KDE Neon (Ubuntu 20.04 base).

I do have LibreOffice Writer open full-time.
libreoffice Version 1:6.4.7-0ubuntu0.20.04.1

Revision history for this message
Wirawan Purwanto (wirawan0) wrote : Re: [Bug 1884850] Re: Xorg server uses unacceptably large amounts of memory (and keep growing) when LibreOffice is running

Dave, I am suspecting a bug with the X hardware driver. Can you please
describe the machine you are using. Plus produce the output of "lspci"
and "lsmod"?

Wirawan

On Thu, Sep 9, 2021 at 6:59 AM DaveQB <email address hidden> wrote:
>
> I have this same issue πŸ™‹β€β™‚οΈ
> KDE Neon (Ubuntu 20.04 base).
>
> I do have LibreOffice Writer open full-time.
> libreoffice Version 1:6.4.7-0ubuntu0.20.04.1
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1884850
>
> Title:
> Xorg server uses unacceptably large amounts of memory (and keep
> growing) when LibreOffice is running
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1884850/+subscriptions
>

--
Wirawan Purwanto
Computational Scientist, HPC Group
Information Technology Services
Old Dominion University
Norfolk, VA 23529

~ https://bfa.org ~
"Get your own copy of a free study Bible"

Revision history for this message
DaveQB (david-dward) wrote (last edit ):

Thanks Wirawan. I was contemplating digging into my driver and switching from Nvidia to Nouveau (although I think Nouveau couldn't drive my new monitor last I tried).

nvidia-driver-460

Gigabyte X570 AORUS MASTER
AMD Ryzen 5 3600
GP106 [GeForce GTX 1060 6GB]

lsmod attached

Revision history for this message
DaveQB (david-dward) wrote :

lspci attached

Revision history for this message
Wirawan Purwanto (wirawan0) wrote :

One point of observation. Since this time, I am switching to Debian 10 for daily work because I couldn't bear X11 memory growth. The package information for my Debian install:

* xserver-xorg version 1:7.7+19
* xserver-xorg-video-intel version 2:2.99.917+git20180925-2
* linux-image-4.19.0-17-amd64 version 4.19.194-3 (stock kernel, unmodified)

This does not produce the same kind of unabated memory growth.

Please let me know if anything can be done to help diagnose the problem. I have not gotten rid of the Ubuntu 20.04 install yet, though I had switched to xfce for daily work, before eventually I installed Debian 10.

Revision history for this message
Eugene Pakhomov (p-himik) wrote :

Pretty sure I'm hitting this issue. I don't use LibreOffice that often but it seems that Xorg memory usage grows without it. But so far I can't really tell what causes it as sometimes it grows relatively rapidly (by hundreds of MB a day) and sometimes the growth stalls.

The output of lsmod is attached.

The output of lspci:
00:00.0 Host bridge: Intel Corporation 8th/9th Gen Core 8-core Desktop Processor Host Bridge/DRAM Registers [Coffee Lake S] (rev 0d)
00:01.0 PCI bridge: Intel Corporation 6th-10th Gen Core Processor PCIe Controller (x16) (rev 0d)
00:08.0 System peripheral: Intel Corporation Xeon E3-1200 v5/v6 / E3-1500 v5 / 6th/7th/8th Gen Core Processor Gaussian Mixture Model
00:12.0 Signal processing controller: Intel Corporation Cannon Lake PCH Thermal Controller (rev 10)
00:14.0 USB controller: Intel Corporation Cannon Lake PCH USB 3.1 xHCI Host Controller (rev 10)
00:14.2 RAM memory: Intel Corporation Cannon Lake PCH Shared SRAM (rev 10)
00:16.0 Communication controller: Intel Corporation Cannon Lake PCH HECI Controller (rev 10)
00:17.0 SATA controller: Intel Corporation Cannon Lake PCH SATA AHCI Controller (rev 10)
00:1c.0 PCI bridge: Intel Corporation Cannon Lake PCH PCI Express Root Port #1 (rev f0)
00:1c.3 PCI bridge: Intel Corporation Cannon Lake PCH PCI Express Root Port #4 (rev f0)
00:1d.0 PCI bridge: Intel Corporation Cannon Lake PCH PCI Express Root Port #9 (rev f0)
00:1f.0 ISA bridge: Intel Corporation Z390 Chipset LPC/eSPI Controller (rev 10)
00:1f.3 Audio device: Intel Corporation Cannon Lake PCH cAVS (rev 10)
00:1f.4 SMBus: Intel Corporation Cannon Lake PCH SMBus Controller (rev 10)
00:1f.5 Serial bus controller: Intel Corporation Cannon Lake PCH SPI Controller (rev 10)
00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (7) I219-V (rev 10)
01:00.0 VGA compatible controller: NVIDIA Corporation TU104 [GeForce RTX 2070 SUPER] (rev a1)
01:00.1 Audio device: NVIDIA Corporation TU104 HD Audio Controller (rev a1)
01:00.2 USB controller: NVIDIA Corporation TU104 USB 3.1 Host Controller (rev a1)
01:00.3 Serial bus controller: NVIDIA Corporation TU104 USB Type-C UCSI Controller (rev a1)
03:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network Connection (rev 03)
04:00.0 Non-Volatile memory controller: Phison Electronics Corporation E16 PCIe4 NVMe Controller (rev 01)

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Eugene,

Please open a separate bug by running:

  ubuntu-bug xorg-server

and also try using 'xrestop' to see which app(s) are causing Xorg to be so large.

To post a comment you must log in.