<div dir="ltr">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.<div><br></div><div>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.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 6 December 2017 at 00:49, Ewen Chan <span dir="ltr"><<a href="mailto:chan.ewen@gmail.com" target="_blank">chan.ewen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thank you, Hi-Angel.<div><br></div><div>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 <font face="monospace, monospace">ps aux</font> command shows Xorg being the culprit for the high memory consumption.</div><div><br></div><div>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).</div><div><br></div><div>X is supposed to release the memory back into the available pool, but it doesn't -- it just keeps increasing.</div><div><br></div><div>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.</div><div><br></div><div>Again, the idea of providing the first link was to limit how much RAM can X use for the caching/retention (using <font face="monospace, monospace">ulimit -m</font> 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.</div><div><br></div><div><br></div><div><img src="cid:ii_jau5jn630_16028a2b8324176c" width="562" height="410"><br><br></div><div><br></div><div>(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).)</div><div><br></div><div><font face="monospace, monospace">xrestop</font> only shows about 22 MiB.</div><div><br></div><div><font face="monospace, monospace">ps aux | grep Xorg</font> is still showing about 100 GiB tied to the Xorg process.</div><div><br></div><div>Thanks.</div><div><br></div><div>Sincerely,</div><div>Ewen</div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 5, 2017 at 4:28 PM, Hi-Angel <span dir="ltr"><<a href="mailto:hiangel999@gmail.com" target="_blank">hiangel999@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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> <div><div class="m_-1724834269670586340h5"><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> </div></div>> ______________________________<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> </blockquote></div><br></div> </div></div></blockquote></div><br></div>