X is consuming ~100 GiB of RAM(!)

Tue Dec 5 23:49:25 UTC 2017

Not really sure.

Someone suggested that I tried Xvfb but I didn't really know how I can use
that without using an X server already, and again, in trying to conduct my
own due diligence research into the issue, I stumbled upon using ssh -Y and
enabling X11 forwarding via ssh so I will have to see how that works next
(unless there are other suggestions that come before that that I can also
quickly test out as well).

Thanks.

On Tue, Dec 5, 2017 at 6:36 PM, Vladimir Dergachev <volodya at mindspring.com>
wrote:

>
> Also, given the the high usage does not happen outside of gnome session,
> perhaps this is connected to compositing..
>
> best
>
> Vladimir Dergachev
>
>
> On Wed, 6 Dec 2017, Hi-Angel 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
>>>
>> _______________________________________________
>> 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/9ca8df7d/attachment-0003.html>