X is consuming ~100 GiB of RAM(!)
Ewen Chan
chan.ewen at gmail.com
Wed Dec 6 02:54:49 UTC 2017
I'm a little bit confused by your reply here.
If it doesn't rely on GL, can you please help clarify why would I want to
use Xvnc instead?
(Was that suppose to be "If it DOES (rely on GL), to use Xvnc instead"?)
Thanks.
On Tue, Dec 5, 2017 at 7:17 PM, Vladimir Dergachev <volodya at mindspring.com>
wrote:
>
>
> On Tue, 5 Dec 2017, Ewen Chan wrote:
>
> 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).
>>
>
> If your app relies on GL you don't want to use ssh -Y.
>
> If it does not, then I recommend running it in Xvnc instead.
>
> best
>
> Vladimir Dergachev
>
>
>
>> 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/pr
>> oducts/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/1d5d8
>> a9c-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/cur
>> rent/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/d6e704bf/attachment-0002.html>
More information about the xorg
mailing list