X is consuming ~100 GiB of RAM(!)

Tue Dec 5 22:42:01 UTC 2017

Oh, wow, this looks like a Xorg bug then. I'd recommend trying latest Xorg
then — yours one is 3 years old, hopefully it's something fixed. If it
won't help, I'd recommend report a bug.

Although ulimit workaround worth a try, but If this is really a memory
leak, I doubt it'd help much. What I think would happen is that Xorg won't
be able to allocate resources on apps' behalf, making apps to crash.

On 6 December 2017 at 00:49, Ewen Chan <chan.ewen at gmail.com> wrote:

> Thank you, Hi-Angel.
>
> I thought so too originally, but when I am launching the analysis via a
> terminal on the console (or even via ssh from cygwin into the system) and
> it is still exhibiting the same behaviour despite the fact that there isn't
> any graphical component running beyond just runlevel 5 (and having GNOME
> running on X), issuing the ps aux command shows Xorg being the culprit
> for the high memory consumption.
>
> In trying to perform the forensic analysis, I would think that it would be
> true if there is a graphic component that's actually running, but there
> isn't (beyond runlevel 5/GNOME-on-X).
>
> X is supposed to release the memory back into the available pool, but it
> doesn't -- it just keeps increasing.
>
> So even after the application has terminated, if X doesn't release the
> memory back, then ps aux will show X as being the process that's holding
> the memory.
>
> Again, the idea of providing the first link was to limit how much RAM can
> X use for the caching/retention (using ulimit -m somehow and editing
> /etc/security/limits.conf) and I raised the question (on the SLES forum)
> how would I know what I should set the limit at? Too low and it will crash
> often. Too high, and I am back to this current problem that I am
> experiencing now.
>
>
>
> 
>
> (sorry that the output of xrestop above is a screenshot because I am twice
> remotely logged in (first to home system and then again via the IPMI to the
> console).)
>
> xrestop only shows about 22 MiB.
>
> ps aux | grep Xorg is still showing about 100 GiB tied to the Xorg
> process.
>
> Thanks.
>
> Sincerely,
> Ewen
>
>
> On Tue, Dec 5, 2017 at 4:28 PM, Hi-Angel <hiangel999 at gmail.com> wrote:
>
>> The troubleshooting link you provided states that the high memory
>> usage typically belongs to some other application. Sorry, I am just an
>> occasional bystander here, and can't tell much of technical details,
>> but I imagine it works like this(I hope someone will correct me on
>> details): an app requests, for example, a glx object, and XServer
>> allocates one. When the app is done with the object, it requests
>> XServer to deallocate it. The point is: although this memory accounted
>> on part of XServer process — it is actually owned by the app. The link
>> also states that you can use `xrestop` application to see the owners
>> and amounts of the memory.
>>
>> On 5 December 2017 at 21:14, Ewen Chan <chan.ewen at gmail.com> wrote:
>> > To Whom It May Concern:
>> >
>> > Hello everybody. My name is Ewen and I am new to this distribution list.
>> >
>> > So let me start with a little bit of background and the problem
>> statement of
>> > what I am seeing/encountering.
>> >
>> > I am running a SuperMicro Server 6027TR-HTRF
>> > (https://www.supermicro.com/products/system/2u/6027/sys-6027tr-htrf.cfm
>> )
>> > (which uses a Matrox G200eW graphics chip and it has four half-width
>> nodes,
>> > each node has two processor, each processor is an Intel Xeon E5-2690
>> (v1)
>> > (8-core, 2.9 GHz stock, HTT disabled) running SuSE Linux Enterprise
>> Server
>> > 12 SP1 (SLES 12 SP1).
>> >
>> > Here are some of the outputs from the system:
>> >
>> > ewen at aes4:~> X -version
>> >
>> > X.Org X Server 1.15.2
>> > Release Date: 2014-06-27
>> > X Protocol Version 11, Revision 0
>> > Build Operating System: openSUSE SUSE LINUX
>> > Current Operating System: Linux aes4 3.12.49-11-default #1 SMP Wed Nov
>> 11
>> > 20:52:43 UTC 2015 (8d714a0) x86_64
>> > Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.12.49-11-default
>> > root=UUID=fc4dcdb9-2468-422c-b29f-8da42fd7dec0
>> > resume=/dev/disk/by-uuid/1d5d8a9c-218e-4b66-b094-f5154ab08434
>> splash=silent
>> > quit showopts crashkernel=123M,high crashkernel=72M,low
>> > Build Date: 12 November 2015  01:23:55AM
>> >
>> > Current version of pixman: 0.32.6
>> >          Before reporting problems, check http://wiki.x.org
>> >          to make sure that you have the latest version.
>> > ewen at aes4:~> uname -a
>> > Linux aes4 3.12.49-11-default #1 SMP Wed Nov 11 20:52:43 UTC 2015
>> (8d714a0)
>> > x86_64 x86_64 x86_64 GNU/Linux
>> >
>> > The problem that I am having is that I am running a CAE analysis
>> application
>> > and during the course of the run, X will eventually consume close to
>> 100 GiB
>> > of RAM (out of 125 GiB installed)
>> >
>> > ewen at aes4:~> date
>> > Tue Dec 5 05:08:28 EST 2017
>> > ewen at aes4:~> ps aux | grep Xorg
>> > root 2245 7.7 79.0 271100160 104332316 tty7 Ssl+ Nov25 1078:19
>> /usr/bin/Xorg
>> > :0 -background none -verbose -auth /run/gdm/aut
>> > h-for-gdm-9L7Ckz/database -seat seat0 -nolisten tcp vt7
>> > ewen 11769 0.0 0.0 10500 944 pts/1 R+ 05:08 0:00 grep --color=auto Xorg
>> >
>> > This does not occur when I perform the same analysis in runlevel 3 and
>> when
>> > I switch back to runlevel 5 and I am using GNOME for the desktop
>> > environment, regardless of whether I initiate the analysis via a
>> Terminal
>> > inside GNOME or I ssh into the system (via cygwin from a Windows box),
>> the
>> > host server's X memory usage will continually increase as the analysis
>> > progresses.
>> >
>> > In trying to research this issue, I have found that I can either
>> restrict
>> > the amount of cache that X does via ulimit -m (Source:
>> > https://wiki.ubuntu.com/X/Troubleshooting/HighMemory) or I can edit
>> > xorg.conf by adding this option:
>> >
>> > Option "XaaNoPixmapCache"
>> >
>> > (Source: https://www.x.org/releases/current/doc/man/man5/xorg.conf.5.
>> xhtml)
>> >
>> > Would that be the recommended solution to the problem that I am
>> experiencing
>> > with X?
>> >
>> > A couple of other notes:
>> >
>> > ewen at aes4:~> free -g
>> >              total       used       free     shared    buffers
>>  cached
>> > Mem:           125        125          0          0          0
>> 3
>> > -/+ buffers/cache:        122          3
>> > Swap:          256        170         85
>> > ewen at aes4:~> cat /proc/sys/vm/vfs_cache_pressure
>> > 200
>> >
>> > Your help and commentary would be greatly appreciated. Thank you.
>> >
>> > Sincerely,
>> >
>> > Ewen Chan
>> >
>> > _______________________________________________
>> > xorg at lists.x.org: X.Org support
>> > Archives: http://lists.freedesktop.org/archives/xorg
>> > Info: https://lists.x.org/mailman/listinfo/xorg
>> > Your subscription address: %(user_address)s
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.x.org/archives/xorg/attachments/20171206/deff372d/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Capture4.PNG
Type: image/png
Size: 255314 bytes
Desc: not available
URL: <https://lists.x.org/archives/xorg/attachments/20171206/deff372d/attachment-0003.png>