X is consuming ~100 GiB of RAM(!)

Tue Dec 5 21:49:49 UTC 2017

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/20171205/b42b7491/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/20171205/b42b7491/attachment-0003.png>