<div dir="ltr">I'm a little bit confused by your reply here.<div><br></div><div>If it doesn't rely on GL, can you please help clarify why would I want to use Xvnc instead?</div><div><br></div><div>(Was that suppose to be "If it DOES (rely on GL), to use Xvnc instead"?)</div><div><br></div><div>Thanks.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 5, 2017 at 7:17 PM, Vladimir Dergachev <span dir="ltr"><<a href="mailto:volodya@mindspring.com" target="_blank">volodya@mindspring.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
On Tue, 5 Dec 2017, Ewen Chan wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Not really sure.<br>
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<br>
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<br>
quickly test out as well).<br>
</blockquote>
<br></span>
If your app relies on GL you don't want to use ssh -Y.<br>
<br>
If it does not, then I recommend running it in Xvnc instead.<br>
<br>
best<span class="HOEnZb"><font color="#888888"><br>
<br>
Vladimir Dergachev</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks.<br>
<br>
On Tue, Dec 5, 2017 at 6:36 PM, Vladimir Dergachev <<a href="mailto:volodya@mindspring.com" target="_blank">volodya@mindspring.com</a>> wrote:<br>
<br>
      Also, given the the high usage does not happen outside of gnome session, perhaps this is connected to compositing..<br>
<br>
      best<br>
<br>
      Vladimir Dergachev<br>
<br>
      On Wed, 6 Dec 2017, Hi-Angel wrote:<br>
<br>
            The troubleshooting link you provided states that the high memory<br>
            usage typically belongs to some other application. Sorry, I am just an<br>
            occasional bystander here, and can't tell much of technical details,<br>
            but I imagine it works like this(I hope someone will correct me on<br>
            details): an app requests, for example, a glx object, and XServer<br>
            allocates one. When the app is done with the object, it requests<br>
            XServer to deallocate it. The point is: although this memory accounted<br>
            on part of XServer process — it is actually owned by the app. The link<br>
            also states that you can use `xrestop` application to see the owners<br>
            and amounts of the memory.<br>
<br>
            On 5 December 2017 at 21:14, Ewen Chan <<a href="mailto:chan.ewen@gmail.com" target="_blank">chan.ewen@gmail.com</a>> wrote:<br>
                  To Whom It May Concern:<br>
<br>
                  Hello everybody. My name is Ewen and I am new to this distribution list.<br>
<br>
                  So let me start with a little bit of background and the problem statement of<br>
                  what I am seeing/encountering.<br>
<br>
                  I am running a SuperMicro Server 6027TR-HTRF<br>
                  (<a href="https://www.supermicro.com/products/system/2u/6027/sys-6027tr-htrf.cfm" rel="noreferrer" target="_blank">https://www.supermicro.com/pr<wbr>oducts/system/2u/6027/sys-6027<wbr>tr-htrf.cfm</a>)<br>
                  (which uses a Matrox G200eW graphics chip and it has four half-width nodes,<br>
                  each node has two processor, each processor is an Intel Xeon E5-2690 (v1)<br>
                  (8-core, 2.9 GHz stock, HTT disabled) running SuSE Linux Enterprise Server<br>
                  12 SP1 (SLES 12 SP1).<br>
<br>
                  Here are some of the outputs from the system:<br>
<br>
                  ewen@aes4:~> X -version<br>
<br>
                  X.Org X Server 1.15.2<br>
                  Release Date: 2014-06-27<br>
                  X Protocol Version 11, Revision 0<br>
                  Build Operating System: openSUSE SUSE LINUX<br>
                  Current Operating System: Linux aes4 3.12.49-11-default #1 SMP Wed Nov 11<br>
                  20:52:43 UTC 2015 (8d714a0) x86_64<br>
                  Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.12.<wbr>49-11-default<br>
                  root=UUID=fc4dcdb9-2468-422c-b<wbr>29f-8da42fd7dec0<br>
                  resume=/dev/disk/by-uuid/1d5d8<wbr>a9c-218e-4b66-b094-f5154ab0843<wbr>4 splash=silent<br>
                  quit showopts crashkernel=123M,high crashkernel=72M,low<br>
                  Build Date: 12 November 2015  01:23:55AM<br>
<br>
                  Current version of pixman: 0.32.6<br>
                           Before reporting problems, check <a href="http://wiki.x.org" rel="noreferrer" target="_blank">http://wiki.x.org</a><br>
                           to make sure that you have the latest version.<br>
                  ewen@aes4:~> uname -a<br>
                  Linux aes4 3.12.49-11-default #1 SMP Wed Nov 11 20:52:43 UTC 2015 (8d714a0)<br>
                  x86_64 x86_64 x86_64 GNU/Linux<br>
<br>
                  The problem that I am having is that I am running a CAE analysis application<br>
                  and during the course of the run, X will eventually consume close to 100 GiB<br>
                  of RAM (out of 125 GiB installed)<br>
<br>
                  ewen@aes4:~> date<br>
                  Tue Dec 5 05:08:28 EST 2017<br>
                  ewen@aes4:~> ps aux | grep Xorg<br>
                  root 2245 7.7 79.0 271100160 104332316 tty7 Ssl+ Nov25 1078:19 /usr/bin/Xorg<br>
                  :0 -background none -verbose -auth /run/gdm/aut<br>
                  h-for-gdm-9L7Ckz/database -seat seat0 -nolisten tcp vt7<br>
                  ewen 11769 0.0 0.0 10500 944 pts/1 R+ 05:08 0:00 grep --color=auto Xorg<br>
<br>
                  This does not occur when I perform the same analysis in runlevel 3 and when<br>
                  I switch back to runlevel 5 and I am using GNOME for the desktop<br>
                  environment, regardless of whether I initiate the analysis via a Terminal<br>
                  inside GNOME or I ssh into the system (via cygwin from a Windows box), the<br>
                  host server's X memory usage will continually increase as the analysis<br>
                  progresses.<br>
<br>
                  In trying to research this issue, I have found that I can either restrict<br>
                  the amount of cache that X does via ulimit -m (Source:<br>
                  <a href="https://wiki.ubuntu.com/X/Troubleshooting/HighMemory" rel="noreferrer" target="_blank">https://wiki.ubuntu.com/X/Trou<wbr>bleshooting/HighMemory</a>) or I can edit<br>
                  xorg.conf by adding this option:<br>
<br>
                  Option "XaaNoPixmapCache"<br>
<br>
                  (Source: <a href="https://www.x.org/releases/current/doc/man/man5/xorg.conf.5.xhtml" rel="noreferrer" target="_blank">https://www.x.org/releases/cur<wbr>rent/doc/man/man5/xorg.conf.5.<wbr>xhtml</a>)<br>
<br>
                  Would that be the recommended solution to the problem that I am experiencing<br>
                  with X?<br>
<br>
                  A couple of other notes:<br>
<br>
                  ewen@aes4:~> free -g<br>
                               total       used       free     shared    buffers     cached<br>
                  Mem:           125        125          0          0          0          3<br>
                  -/+ buffers/cache:        122          3<br>
                  Swap:          256        170         85<br>
                  ewen@aes4:~> cat /proc/sys/vm/vfs_cache_pressur<wbr>e<br>
                  200<br>
<br>
                  Your help and commentary would be greatly appreciated. Thank you.<br>
<br>
                  Sincerely,<br>
<br>
                  Ewen Chan<br>
<br>
                  ______________________________<wbr>_________________<br>
                  <a href="mailto:xorg@lists.x.org" target="_blank">xorg@lists.x.org</a>: X.Org support<br>
                  Archives: <a href="http://lists.freedesktop.org/archives/xorg" rel="noreferrer" target="_blank">http://lists.freedesktop.org/a<wbr>rchives/xorg</a><br>
                  Info: <a href="https://lists.x.org/mailman/listinfo/xorg" rel="noreferrer" target="_blank">https://lists.x.org/mailman/li<wbr>stinfo/xorg</a><br>
                  Your subscription address: %(user_address)s<br>
<br>
            ______________________________<wbr>_________________<br>
            <a href="mailto:xorg@lists.x.org" target="_blank">xorg@lists.x.org</a>: X.Org support<br>
            Archives: <a href="http://lists.freedesktop.org/archives/xorg" rel="noreferrer" target="_blank">http://lists.freedesktop.org/a<wbr>rchives/xorg</a><br>
            Info: <a href="https://lists.x.org/mailman/listinfo/xorg" rel="noreferrer" target="_blank">https://lists.x.org/mailman/li<wbr>stinfo/xorg</a><br>
            Your subscription address: %(user_address)s<br>
<br>
<br>
<br>
</blockquote>
</div></div></blockquote></div><br></div>